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Abstract 


Traditionally, abstraction in planning has been. accomplished by either state abstrac- 
tion or operator abstraction, neither of which has been fully automatic. We present 
a new method, predicate relaxation , for automatically performing state abstraction. 
Predicate relaxation generates absti action hierarchies that, for Some domains, can be 
more useful than those generated, by previous abstraction mechanisms. PABLO, a 
nonlinear hierarchical planner, implements predicate relaxation. Theoretical, as well 
as empirical results are presented, which demonstrate the potential advantages of us- 
ing predicate relaxation in planning. Relaxed predicates can also be used by PABLO 
to achieve a limited form of reactivity, whereby an executable sequence of actions is 
constructed in case of interruption. 

We also present a new definition of hierarchical operators that allows us to guar- 
antee a limited form of completeness. This new definition is shown to be,_in some 
Ways, more flexible than previous definitions of. hierarchical operators. The ability to 
plan using such operators has been incorporated into PABLO. 

Finally, a Classical Truth Criterion is presented that is proven to be sound and 
complete for a planning formalism that is general enough to include most classical 
planning formalisms that are based on the STRIPS assumption. 
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Chapter 1 

Review of Abstraction in Planning 


One of the powerful tools employed by planners to deal with the complexity of plan- 
ning problems is aostraction. Although widely used, and in many guises, abstraction 
remains relatively poorly understood. Because of this, systems employing abstrac- 
tion have usually left the definition of the abstractions up to the user of the system. 
This thesis introduces a new method for performing abstractions automatically and 
presents results related to abstraction in planning which should help to clarify the 
potential benefits, as well as drawbacks, of using abstraction in planning. In this chap- 
ter, we present the different methods of abstraction employed up until now, pointing 
out some potential problems along the way. 

The rest of the thesis is organized. as follows. Chapter 2 introduces predicate re- 
laxation, a new method for performing automatic abstraction in planning. Chapter 3 
presents PABLO, a nonlinear planner that implements predicate relaxation. Chapter 
4 discusses theoretical results pertaining to the complexity of using predicate relax- 
ation in planning. Chapter 5 presents empirical results demonstrating the increased _ 
efficiency gained when using predicate relaxation in planning. Chapter 6 discusses 
how an extension to predicate relaxation can.be used to achieve a limited form of 
reactivity in planning. Chapter 7 discusses a method for performing operator hierar- 
chicalization in planning, which guarantees a limited form of completeness. Chapter 8 
describes how both abstraction techniques can be used effectively in planning. Chap- 
ter-9 describes a new .truth criterion for planning which is based on a very_general 
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CHAPTER 1. REVIEW OP ABSTRACTION IN PLANNING 


planning formalism. Finally, chapter 10 discusses open problems and further Work 
that needs to be done in the area of abstraction in planning. 


1.1 Basic Concepts 

When thinking about abstraction it is often useful to do so in the context of a state 
space graph. In such a graph each node corresponds to a particular world state, 
and each directed arc to a particular operator which transforms that world state into 
another. Figure 1.1 is. an example of a general state space graph. 



Figure 1.1: State space graph 

It is the task of a planner, when given a description of a particular initial state in 
the state space graph as well as a description of one or more desired goal states , to - 
discover one or more paths from the initial state to one of the goal states. Of course 
the state space graph is often prohibitively large, possibly infinite, and is therefore 
not usually explicitly represented. Rather, the state space graph is implicitly defined 
by a set of operators, i.e. functions from states to states. Parts of the state space 
graph can be constructed from the set of operators and a given state by applying 
all possible operators to the given state, repeating the process for all newly created 
states— For a planning problem to be solvable it is necessary that one of the goal 
states can be constructed in this manner from the initial state. 

Generally, when we speak of abstraction in planning, it is implied that one of more 
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elements of a planning problem is being abstracted, i.e. either the initial state, One 
or more of the operators, or the goal states. As we shall see, it has generally been the 
Case that planning systems have concerned themselves with abstracting operators. 

Abstraction has been used as a mechanism in planning for two reasons. First, it is 
a natural extension, and one which people often use when doing everyday planning. 
Second, it is likely that planning with abstractions improves the efficiency of the 
planner. 


1.2 Previous Work 
1.2.1 STRIPS Assumption 

Early work in planning [Green, 69] led to the discovery of severe deficiencies in trying 
to apply theorem proving to the planning problem. One of the main problems was 
the need for frame axioms [McCarthy and Hayes, 1969], axioms which stated what 
remained true from one state to the next. As it turns out many, such axioms, are 
generally needed for most planning problems. 

STRIPS-JFikes and Nilsson, 1971] embodied one approach for dealing with this 
problem. In STRIPS, operators were structures consisting of a precondition list, a 
delete list, and an add list. States were sets of well-formed formulas. An operator 
was applicable in a state if all the items in the precondition list could be unified with 
members. of the state. The result of applying an operator was that items in the delete 
list were deleted from the state, and items in the add list were added to the state. 

These operators embodied What has come to be known a&the STRIPS assumption 
- that whatever is not explicitly listed as an effect in an operator is automatically 
copied to the new state. The STRIPS assumption has proven an effective approach 
to the frame problem, obviating the need for time consuming frame axioms. Virtually 
all subsequent planners make use of the STRIPS assumption in some form. Some 
of the newer planners relax the STRIPS assumption somewhat in return for more 
flexibility in operator representation [Wilkins, 1988]. 

When subsequently we refer to operators we will mean STRIPS style operators, 
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unless we specify otherwise. We now discuss some of the previous work on abstracting 
planning problems. 

1.2.2 Macro Operators 

One way an implicit state space graph can be abstracted is by defining new operators. 
One useful mechanism is to create new macro operators , each of which is the result 
of composing a sequence of two or more operators. Doing so allows the planner 
to traverse the state space graph more quickly, since intermediate, and presumably 
unimportant states, can be bypassed when transforming one state into another state. 

The use of macro operators can be. found in one of the earliest discussions on the 
use of abstraction in problem solving, namely Amarel’s classic paper [Amarel, 1968]. 
Amarel traces a solution to the Missionaries and Cannibals problem which involves 
the introduction of macro operators, as .well as other forms of abstraction which we 
will discuss later. Through these methods Amarel demonstrates how a seemingly com- 
plicated problem can be transformed into a trivial One by exploiting useful properties 
of the state space graph. 

One of the first examples of an abstraction method being implemented in a planner 
is the use of MACROPS in STRIPS [Fikes et al, 1972]. A MACR.OP is a macro 
operator, composed automatically by STRIPS from a Successful plan. This is done 
by storing the plan in a triangle table and then generalizing it. by turning constants 
into variables. This-generalized plan becomes a MACROP and can then be used by 
STRIPS to speed up planning considerably. 

1.2.3 Hierarchical Operators 

Although macro operators proved successful in STRIPS, their sequential was a limita- 
tion. -NOAH [Sacerdoti, 1977] introduced the idea of least commitment to planning. 
Plans id NOAH were no longer represented simply as linear sequences of operators, 
but rather as partial. orders of operators, compactly representing a set of total orders. 
These partial orders were represented in a procedural net. NOAH is the first example 
of a planner that searches in a space of partially ordered plans rather than the base 
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state space provided by the domain. Strictly speaking, NO AH did not search this 
space, since no backtracking mechanism was incorporated. 

In NOAH, macro operators were generalized, so that they no longer were simply 
compositions of sequences of operators, but rather were procedural encodings which, 
when executed, would produce a portion of a procedural net. These operators are 
termed hierarchical operators, and executing their procedural encodings is referred 
to as expanding an operator. The actual result of.an operator expansion in NOAH 
might depend on the situation in which the operator is expanded, so there is not a 
simple one to one relationship between the hierarchical operators and partial orders 
of base level operators. 

The use of hierarchical operators has been by far the most commonly used abstrac- 
tion mechanism in planning since the advent of NOAH. Almost all ensuing planners 
employ some form of hierarchical operators, including NONLIN_[Tate, 1977] and SIPE 
[Wilkins, 1988]. 

Unlike MACROPS in STRIPS,. there is no example of a planner which learns 
hierarchical operators from the basic domain operators. Rather, they must be encoded 
by the user of the planner. 

Because macro operators and hierarchical operators are defined in terms of other 
operators, these mechanisms will be termed operator abstraction mechanisms. 

1.2.4 State Abstraction 

Another planner that utilizes abstraction is ABSTRIPS [Sacerdoti, 1974].. It is based 
on STRIPS [Fikes and Nilsson, 1971] and utilizes a. different abstraction mechanism 

from operator abstraction. Before proceeding it is important to have an understanding 

of the basic planning mechanism employed by ABSTRIPS. 

ABSTRIPS abstracts by assigning. criticalities to predicates. -A criticality indicates 
the relative difficulty of making the particular predicate true in the domain, with the 
highest criticalities being assigned to predicates which cannot be affected byjthe 
planner. 

Planning in. ABSTRIPS proceeds in a “length-first” manner. At each stage a 
threshold criticality is determined. The planner then performs a complete STRIPS 



6 


CHAPTER 1. REVIEW OF ABSTRACTION IN PLANNING . 


planning procedure, the sole difference being that, predicates which have criticalities 
less than the current threshold, are assumed to hold. The idea behind this is that 
those predicates can in some sense be considered details and can be achieved relatively 
easily. After each pass ABSTRIPS lowers the Criticality threshold and proceeds to 
refine the current plan by attempting to achieve predicates which are- now above 
the threshold. Planning is complete Once the threshold is less than the smallest - 
criticality. Using this method, Sacerdoti was able to achieve great speedup on some 
problems when compared to the bare-bones STRIPS system. The criticality values 
were generated in a semi-automatic manner, with the user providing a partial order, 
of predicates which ABSTRIPS would use in assigning crticality values. 

Since at any planning level, the preconditions of operators that have a criticality 
lower than the threshold will be dropped, each planning level consists of a new, 
abstract set of operators. Because an operator at one level is applicable in a superset 
of states from its corresponding operators at lower levels, this form of abstraction is 
termed state abstraction . 

Tenenberg [Tenenberg, 1988] extends the ABSTRIPS representation by including 
criticality levels in the add and delete lists of operators. This, combined with a 
restricted method for computing the criticalities of predicates, produces a system 
which guarantees that planning at all levels of abstraction is consistent, which was 
not the case in the original ABSTRIPS system. 

The problem is that if one is not careful when assigning criticality values it is 
possible to generate plans at higher levels of abstraction which result in inconsistent 
states. For example, Tenenberg presents the problem depicted in figure 1.2 in his 
thesis. 

In the example the set L-defines the language of the system, the set E is the 
set of essential predicates, namely those predicates which can be manipulated by the 
operators, 0 is the set Of operators, K is a set of domain axioms, and crit is the set 
of criticality mappings on the predicates. 

If the initial situation is described by 


{On{A, B), Clear(A), Holdirig(C)} 
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L. (constants^ {A,B, C}), (variables =={x, y, 2 }) (functions = 0), 

(predicates — {On, Clear, HandEmpty, Holding, *}) 

E = {On, Clear, HandEmpty, Holding}, 

0 = {unstack(x,y) stack(x.y) 

P:{On(x, y), Clear(x), HandEmpty}, P:{Clear(y), Holding(x)}. 

D:{On(x, y), Clear(x), HandEmpty}, D.{Clear(y), Holding(x)}, 
A:{Hdlding<x) t Clearly)}, A:{On(x, y), Clear(x), HandEmpty}} 


K-{ Holding(x) Ay»x D ”’Holding(y), 

HandEmpty D -»Holding(x), 

Clear(x) D -»On(y,x), 

On(x, y) D “>On(y, x), 

~'On(x, x), 

A*B, B*C, A*C}. 

crit=s{<On, 1 >,.< Clear, 1>, < HandEmpty, 0>, < Holding, 0>} 

Figure 1.2: ABSTRIPS Example from Tenenberg 


then the plan < unstack(A, B) > is applicable since the preconditions with criticality 
level 1 are satisfied. However, applying the plan results in the state 


{ Holding{C),Holding(A),CUar{B )} 


which is inconsistent with the domain axiom which states that two blocks cannot be 
held at the same time. 

Tenenberg proposes a way of assigning criticality Values which guarantees that 
such inconsistencies do not occur. As We shall see later, our technique of predicate 
relaxation avoids this problem as well, albeit in a different manner. 

Knoblock [KnOblock, 1990] uses a graph theoretic technique to identify depen- 
dencies among predicates in order to remove progressively more predicates at higher 
levels of abstraction. This results in abstractions which guarantee that if there is a 
plan at a high level of abstraction, there will be one at a lower level as well. 
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1.2.5 Discussion 

In actuality, there is not Such a clear dichotomy between the state, and operator 
abstraction in their implementations. .Hierarchical operators can be used to achieve 
state abstraction. This can be done by defining hierarchical operators which do not 
reference all the necessary predicates referenced by the operators, Or their refinements, 
in their bodies. This is similar to the ABSTRIPS approach, but differs in that there is 
no enforcement of explicit . abstract levels, as is the Case with the explicit assignments 
of criticalities. Although more flexible, this lack of explicit criticality levels gives 
rise to “hierarchical promiscuity” [Wilkins, 1988], which can result in unnecessary 
planning. The problem arises when the planner tries to determine the truth value 
of a predicate, call it P. This is generally done by baCkchaining through the plan 
looking for places where P is changed. If operators are represented at different levels 
of abstraction there might be .cases where the refinement of an operator results in a 
change to P , but this is not apparent at the current level of abstraction. In such cases, 
the truth value of P cannot be correctly determined. As we shall see later, there are 
several possible solutions to hierarchical promiscuity, but it remains a serious issue in 
planning with abstraction. 

Furthermore, state abstraction generally results in the generation of new opera- 
tors, which are used to generate the abstract state space. Although the exact dif- 
ferences between state and operator abstraction are not always obvious it-remains a 
useful concept for distinguishing the two types of abstraction. 


1.3 Theoretical Results on Abstraction 

One might_ask by how much abstraction improves planning efficiency. Empirically, 
it seems abstraction can be of -great help. ABSTRIPS was able to achieve significant 
speedups in planning time as compared to STRIPS. The adherence to hierarchical 
operators in post- NOAH planners indicates that they are of great value in improving 
planning efficiency. There are also a few theoretical results to back up the value of 
abstraction in planning. 

Korf [Kdrf, 1987] proves that under certain restrictive assumptions the optimum 
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abstraction hierarchy of a state.space of size n consists of In n levels of abstraction. 

Further, such an abstraction can reduce the expected search time from 0(n) to 0(log 

n). If n grows exponentially with the length of the plan, as is often the. case, this 

result im plie s that the state Space can be Searched in linear time, given the abstraction 
hierarchy. 

However, Korf makes one especially restrictive assumption, namely that a plan 
at one. level maps directly to a.plan at a lower, level. This is usually not the case in 
planning, e.g. in ABSTRIPS. Rather, once a plan has been found at a higher level, 
more planning is necessary to develop the plan at the lower level. The plan at the 
higher level acts as a guide and proposes subproblerns to be solved. 

KnobloCk [Knoblock, 1990] has analyzed this more general problem. However, it 
is difficult to arrive at useful results unless several new assumptions are made. The 
assumptions are as follows. First, if there is a solution at an abstract level, there is one 
at a lower level. This property is referred to as downwards-compatibility. Second, at 
one level of abstraction, each subproblem defined by the abstract level is independent., 
so that no backtracking is necessary. Third, every subproblem of an abstraction level 
is of the same size. Finally, the abstract planner produces the shortest solution. 

Given these assumptions Knoblock derives that the worst case complexity of plan- 
ning is reduced from 0(b l ) to 0(1), where b is the branching factor of the search space, 
and l is the length of the solution plan. This is analogous to. Korf ’^.result. 

Korf’s and Knoblock’s results are very encouraging in. that they suggest abstrac- 
tion can transform intractable combinatorial problems into tractable ones. However, 
in practice, the . restrictive assumptions made may not hold, and. the results may 
not always be as spectacular.. Specifically, the. abstraction spaces may not. satisfy 
downward-compatibility, meaning that a plan at a higher level has no expansion at 
a lower level. It is also possible that the subproblems defined at lower levels are not 
really independent, thus necessitating backtracking across subproblems at one level of 
abstraction. -Nonetheless, these results provide an impetus. for continued research on 
abstraction. It is also clear that human problem solving often. makes use of abstrac- 
tions when planning. Capturing this ability remains a strong motivation for pursuing 
research on abstraction. 
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1.4 Conclusion 

Previous work on abstraction in planning falls under one of two rubrics, either opera^ 
tor abstraction, the most commonly used, Or state abstraction. Hierarchical operators 
are generally considered useful for performing operator abstraction, although they can 
be used for state abstraction as well. -ABSTRIPS.-was able to successfully perform 
state abstraction by assigning criticality values to predicates in the preconditions of 
operators. Finally, theoretical results Suggest that planning can, in the best case, 
reduce planning time from exponential in the len gth of the p lan down to linear. 



Chapter 2 

Predicate Relaxation 


2*1 Introduction 

In this chapter, we introduce predicate relaxation , a method for automatically per- 
forming state abstraction. The motivation for defining predicate relaxation is the 
need for determining whether a predicate should be considered a detail in a particu- _ 
lar situation. As we have seen, AB STRIPS accomplishes this by associating criticality 
values with predicates. However, whenever a predicate has a criticality value lower 
than the current planning threshold that predicate is true in all states of the search 
space. We will argue that whether ? predicate should be considered a detail depends 
on the situation in which we are evaluating the predicate. 

Consider the following example. Suppose we are planning a bus trip from one 
location in a city, to another. When planning at a high level of abstraction, we 
world generally ignore the issue of whether or not we have adequate bus fares and 
concentrate on the route planning aspects of the problem. At high levels of abstraction 
we would like to consider having a bus fare a detail. However, if our plan is to be 
executed fairly soon, and We do. not have exact change in our pockets, getting the 
exact bus fare might not be trivial, and we should not treat having the bus fare as a 
detail. However, if the first bus stop is close to a token booth, it should be relatively 
easy to obtain the bus fare, in which case it becomes a detail again. This, of course, 
presupposes that we have enough money to buy a token. If not, having bus fare ceases 
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to be a detail again. 

The point should be obvious. Whether or not having the bus fare should be 
considered a detail depends on the situation. In some situations obtaining the bus 
fare is trivial, in others it -is more involved and requires some planning. ABSTRIPS’s 
approach of using criticality values is unable to capture this context-dependency, and 
we. are led to defining predicate relaxation. 

The basic idea behind predicate relaxation is that, given a base level predicate P, 
a new predicate P} ct is defined which is true in a superset of states in which P holds. 
We say that P} 6l is a relaxed version of P. 

The above process can be repeated by defining P? it from P} eh and so on, creating 
a hierarchy of predicates. Of course, once, a predicate has been relaxed to the point 
that it holds in all states there is no need to relax it further. 

When we plan, if instead of using the original predicates, we use the newly defined 
relaxed predicates, we can decide if a predicate should be considered a detail by 
checking its relaxed definition. If the relaxation holds we say that the predicate is a 
detail and we do not plan for it. We will see later how this satisfies our requirement 
of context-dependency. 


2.2 Computing Predicate Relaxation 

Predicate relaxation defines a new predicate P} tl from a predicate P in Such a way — 
that . P} K i holds in all states in which P holds and in all states in which P can be 
achieved by the application of one operator. 

In order to precisely define predicate relaxation, regression must be introduced. 
Waldinger [Waldinger, 1977] introduced the technique of regression-in the AI liter- 
ature, although he credits [Manna, 1968, Hoare, 1969, King, 1969] with the original 
discovery. 

Definition 1 The regression Reg{o,p) of predicate P over action o is the weakest 
relation that ensures the subsequent truth of P after executing c. 

Regression can now be used to define predicate relaxation. 
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In .a domain with m operators, given a predicate P, we define P* el as follows: 



p?. , = pzyR‘s(0p„pz') 


where Reg(Opi , P) is the regression of predicate P through operator Opi. 

In general, P will have a non-zero arity, e.g. Clear(x) or On(A,B). When 
computing predicate relaxation, we will usually only do so once for each predicate, 
and replace its arguments with schema variables. For example, after computing the 
relaxation of On(x,y), the result can be instantiated to the predicates On(A,B), 
On(C, D), etc. There is no need to compute the relaxation. expression separately for 
each different predicate. 

It is also the case that P r ” ; becomes more complex as n grows. It should be 
noted that the regression of P? el is always computable, although the complexity of 
the computation may increase with the complexity of P r " ; . 

To improve the efficiency of computation one can check before regressing a pred- 
icate P that it appears in the add list of the operator. If it does not the regression is 
not necessary (the resulting expression would simply be subsumed by P). This does 
not .mean that we never regress predicates through operators where they do not ap- 
pear in the add list. If we are regressing P A Q through an operator where P appears 
in the add list, we must also regress Q throu gh t he same operator, even though it 
might not appear in the add list. . 

In many cases the regression of a predicate through an operator will be equivalent 
to the preconditions of the operator with the appropriate variable instantiations. 
However, there are possible complications. For example, suppose we are regressing 
the predicate P{x) through and operator and P(y) appears in the delete list of the 
operator, but not in the add list. Then, one of the conjuncts in the resulting expression 
will be £ 7 ^ y, to guarantee that P(x) is not deleted by the application of the operator. 

We will see later how we can use relaxed predicates to considerably speed up plan- 
ning. We now provide an example to help the reader become familiar with predicate 
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relaxation. 


2.3 Predicate Relaxation Example 

Suppose we have a blocks-world system with the following four operators, where P is 
the precondition list, D is the delete list, and A is the add list. 

Pickup(x) 

P : { Clear ( x ) ,Handempty } 

D:{Clear(x),Handempty} 

A:{Holding(x)} 

Putdown(x) 

P:{ttolding(x)} 

D:{Holding(x)} 

A : { Clear (x),Handempty) 

Stack(x,y) 

P:{Clear(y),Holding(x)} 

D:{ Clear (y),Holding(x)} 

A:{On(x,y),Clear(x),Handempty} 

Unstack(x,y) 

P:{On(x,y),Clear(x),Handempty} 

D:{On(x,y),Clear(x),Handempty} 

A:{Hplding(x),Clear(y)}__ 


To simplify the example we assume only two blocks A-and B. 

The predicates would be relaxed as follows: 

Hattderiiplyl't - Hatutempty V Holding(x) V (H dlding(y) A Clear(z)) 
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which can be simplified to: 

Haridempiylet = Handempty V Hoi ding (x) 
which in turn call be reduced to: 

Handemptylet = T 
assuming normal domain constraints. 

Here we see that Handempty can easily be guaranteed to hold. 

Proceeding, 

Clear\ el {x) = Clear(x) V Holding(x) V ( Clearly ) A Kolding(x)) 

V(On(z,x) A Clear(z) A Handempty) 

Clear\ tl (x) = Ctear(x) V Holding(x) V (On(z,x) A Clear(z) A Handempty) 

Although it might not be obvious at first glance, using appropriate domain con- . 
Straints and the fact that we have only two blocks the above formula reduces to: 

Clearl el (x) = T 

Next we relax H olding(x): 

H dldingl el (x) = Holding(x) V (C7ear(a:) A Handempty) 

V(On(X, y) A Clear(x) A Handempty) 

Holdingl e l (x) = Holding(x) V (Ctear(x) A Handempty) 

At the next step we-rdax Clear(x) A Handempty : 


Holding] tl {x) = Holding(x)V 
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((Clear (x) V H olding(x)) A (Handempty V Holding ( 2 ))) 

Note that unlike our independent derivation of Clearly we could not use_the . 
preconditions of the Unstack operator, Since UnStaCk clobbers Handempty. 

We can simplify: 

H 'dlding^i(x) — Holding(x) V Clear (x) 

H oldingf e ,(x) = Holding(x) V Clear(x) V (On(z,x) A Clear(z) A Handempty) 
Using the fact that we have only two blocks this reduces to: 

Holding z rel (x) = T 

All that .remains is to-relax On(x,y). 

Onl el (x,y) = On(x,y) V (Clear(y) A Holding(x)) 

As before we can replace Clear(y ) A Holding(x) by Holding(x). 

On l re i(x , y) = On(x y y) V Holding(x) 

Then, relaxing Holding(x), 

Onl el (x,y) = On(x,y) V Holding(x) V (C/ear(z) A Handempty) 

Relaxing Clear(x) A Handempty, 

On* e i(x,y) = On(x,y) V Holding(x) V (C/e<ir(z) A Handempty) V Holding(y) 
Finally, relaxing Holdiiig(y) we get, 

0ft* e/ (z,y) = On(x,y) V Holding(x) V (C/ear(x) A Handempty) 

VHoldirig(y) V (Clear(y) A JHandempty) 

In our simple two blocks domain this reduccs to: 

On:„(x t y) = T 
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2.4 Discussion of Predicate Relaxation 

It should be obvious .that if P r ”, holds in a state, there is a plan which can achieve P 
in n steps or less. The plan is just the sequence of operators through which P was 
regressed to arrive at the expression that holds in the current state. However, because 
we likely simplified the regressed expression along the way, we do not necessarily know 
what this plan is. We just know that there is indeed Such a plan. By the definition of 
regression, this expression being true guarantees that P will hold after the application 
of that Sequence of operators. 

If P" e( holds, but Qr'i does not, one can say that P r n e( is more of a “detail” than 
Q" et , since P can be achieved more easily than Q. Predicate relaxation provides a 
gradual widening of the states in which a predicate holds. In ABSTRIPS, a predicate 
can either hold in those states in which it was intended to hold, or, when its criticality 
value is less than the current threshold, hold in all states of the domain. This change in 
the semantics of a predicate can be quite sharp. Predicates abstracted .with predicate 
relaxation, however, avoid this, semantic cliff, since the set of states in which they 
hold is gradually enlarged at each relaxation level. 

Unlike ABSTRIPS, the abstraction hierarchy is computed automatically. In AB- 
STRIPS the-user had-to supply a partial order of predicates which was used to 
compute criticality values. It is not .always obvious what this partial order should be. 

Also, besides the semantic cliff that ABSTRIP’s method suffers .from there is a 
more subtle problem. . Because of the way criticality values are Computed by AB- 
STRIPS it often happens that one predicate will have different criticality Values in 
the preconditions of different operators. For example, in the example presented in 
[Sacerdoti, 1974] the following operators are presented: 


Gothrudr(R,d»ry) 

P:{[6]Type(d,Door),[5]Infoom(R,rx),[6]Connects(d,fx,ry), 
[2]Status(d, Open), [6]Type(ry, Room)} 
D:{Nextto(R,$l),Inroom(R,rx)} 

A:{Inroorii(R,ry)} 
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Close(R,d) 

P:{[6]Type(d,Door),[5]Nextto(R,d}45]Status(d,Open)}_ 

D:{Status(d,Open)} 

A:{Status(d, Closed)} 


In the Gotkrudr operator the Status(d,Open) precondition has a criticality value 
of 2, whereas in the Close(R,d) it has a criticality of 5. This means that in the same 
situation, .when planning at a criticality threshold between 2 and 5, ABSTRIPS treats 
Status(d,Open) as a detail for one operator, but as an important predicate that needs 
to be planned for in another operator. This type of inconsistency does not happen 
with predicate relaxation. 

In the next chapter we will have more to say about the differences between plan- 
ning with predicate relaxation and ABSTRIPS. 

2.4.1 Context^dependency 

It should be clear that predicate relaxation Can be used to satisfy our requirement 
that the dctailness of a predicate should depend on the situation in which the pred- 
icate is being evaluated. Using our previous example of the .bus fare,. at abstraction 
level ft,. we will consider Have(BusFare) to be a detail in any situations in which 
Havc* el (BitsFare) holds. In this manner, Have(BusFare) will be considered a de- 
tail only in. those situations in which there is a plan of length n or less to achieve 
Hat)t(BusFare). This seems to be a reasonable criterion for determining when a 
predicate should be considered a detail. 


2.5 Summary 

We have introduced predicate relaxation , a method for defining hierarchies of predi- 
cates. Predicate relaxation is a technique for performing state abstraction. We have 
also compared predicate relaxation to ABSTRIPS’s technique of computing criticality 
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values. The basic motivation for using relaxed predicates is the context-dependency 
of detailness. Using. predicate relaxation gives us a means for determining in which 
situations a predicate should be considered a detail. 

In the next chapter we will see how the hierarchies generated by predicate relax- 
ation can be used to significantly improve planning efficiency. 



Chapter 3 
PABLO 


3.1 Introduction 

Since the advent of NOAH [Sacerdoti, 1977] much of planning research has concerned 
itself with developing representational^ powerful planners. Researchers have pro- 
duced planners that are quite encompassing in the domains they can represent, in- 
corporating resource-based reasonin g, t emporal reasoning, and other techniques to 
facilitate the encoding of domains. 

NOAH has had a great influence on modern day planning research. Virtually all 
subsequent planners employ some-of the techniques introduced in NOAH, the most 
distinguishing one being the encoding of plans in ptoceduf&l nets. Procedural nets 
provide a convenient representation for plans. They allow the planner to. represent 
plans as partial orders, rather than as. linear sequences as had previously been the 
case, which allows NOAH to postpone commitment to any particular action ordering 
until absolutely necessary. 

One important characteristic of the procedural net is that it encodes procedural 
as well as declarative information. The procedural data is stored in terms of user 
defined functions (SOUP code functions, in the case of NOAH) for expanding nodes 
in the procedural network at the next planning level.. 

A proctdural net is -procedural precisely because it not only encodes information 
about the problem at hand, but also because it encodes information on how the 
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problem is to be solved. . 

However, with this focus on representational power, there has. also been a shift _ 
away from general, domain independent problem-solving. NOAH signaled this shift 
by providing no backtracking search capability. Thus, if NOAH mistakenly chose a 
wrong operator_with which to expand a subgoal, it had no provision for backing up 
and attempting another operator. — 

Because of its lack of backtracking, a plan in NOAH is basically unfolded, from 
the operator definitions. It is the responsibility of the user to provide NOAH with 
correct and detailed enough SOUP functions so that the planning problem can be 
solved without backtracking. NOAH .can be viewed as a programming language for 
writing programs that compute plans composed of primitive actions. 

It is important to note that NO AH’s lack of a backtracking mechanism, which at 
first glance appears to be a serious omission, is closely tied to the planning philoso- 
phy embodied in NOAH. Of course, the least-commitment principle embodied in the 
procedural net, allowed NOAH to avoid many dead-ends that purely linear planners 
would have encountered, thus further reducing the need for a search capability. 

However, just as importantly, unlike previous planners, the aim was to provide a 
framework wherein the user could apply domain-specific knowledge to solve complex 
planning problems. 

NOAH shifted a major part of the problem-solving responsibility from the planner, 
where it had previously resided, squarely onto the shoulders of the user. This had the 
advantage of greatly, enhancing the computational efficiency of NOAH as compared 
to previous planners. 

Of course, not all the problem-solving responsibility lies with, the user. There is, 
after all, much declarative information in the procedural net that NOAH makes use 
of. Specifically, after each level is expanded a set of critics examines the current state 
of the plan and modifies it in case of difficulties, e.g. the possible clobbering of a 
precondition by an action. 

It has generally been assumed that this division of labour between the domain- 
specific SOUP functions and the domain- independent critics provided an adequate 
compromise between the conflicting requirements of completeness and efficiency in 
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planning. We will argue that this position needs to be-re-examined. We believe there 
is still much to be done in the area of developing powerful planners and that it might 
be necessary to ev entually endow planners with more powerful domain independent 
techniques. 

This is based on the belief that planners should strive to provide as much problem- 
solving Slid as possible to the user attempting to solve a planning problem. The more 
burden we place .On the encoder of the domain, the less valuable a tool the planner 
becomes. Ideally, when faced with a new domain, the user should not have to discover 
the efficient algorithms for solving problems in that domain, but should be able to 
simply provide the planner with a naive encoding of the domain objects and primitive 
actions. 

For example, if faced with the Towers of Hanoi problem, for the first time it does 
not seem reasonable to expect the encoder of the domain to know about efficient 
algorithms for solving the problem. If she did indeed know such algorithms it would 
probably be more reasonable to encode them directly in a general programming lan- 
guage. 

Rather, we can expect the encoder of the domain to provide descriptions of the 
objects and relations of.the domain, e.g. pegs, disks, clear(disk), on(diskl,disk2), 
smaller(diskl,disk2), etc... The only action the encoder is likely to be aware of is the 
Move(diskl,pegl,peg2) action, namely move diskl to.pegl from peg2. This level of. 
information is. realistically all that can be expected from, the encoder of the domain. 
It is then up to the planner to make use of this domain description to facilitate the 
development of plans for .solving problems in this domain. . 

Clearly, because of its lack of backtracking, NOAH is likely to fail to produce plans 
in this domain. Given only the naive encoding of the domain, search is inherently 
necessary in arriving a solution. Of course, search is not the whole answer. If the 
planner merely provides a blind search capability, e.g. complete breadth-first search, 
it is not aiding the user of the. system appreciably. 

Ther lore, it is not simply enough that the planner take responsibility for the 
problem-solving in a domain, it must do so in a non -trivial way to be of aid to the 


user. 
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Many of the advancements in planning since NOAH have .been in the area of 
allowing more representational power by the encoder of the domain, but very few 
have been in the area of improving the .basic problem-solving capabilities, of planners. 
Blind search still seems to be the default for most planners. _ 


3.1.1 Post-NOAH Planners 

The next major planner after NOAH was NONLIN [Tate, 1977] developed by Austin 
Tate at Edinburgh. NONLIN improved on NOAH in several ways. Unlike NOAH, it 
searched the space of partial plans. It also provided a more perspicuous language in 
which to represent operators, as well as typed preconditions. However, its search is 
blind, making its usefulness somewhat questionable. Tate states [Tate, 1977]: 

We expect that the first choice taken should lead to a solution. ..if 
failure occurs with the first plan being considered, our experience is that 
backtracking can lead to long search es. 

Unless the problem domain was encoded in such a way that the solution Could, 
be directly unfolded from the operator definitions, there was a slim hope of finding a 
solution in a reasonable amount of time. 

SIPE [Wilkins, 1984] represents the state of the art in classical planning. In addi- 
tion. to the planning features discussed to this point, SIPE extends the plan represen- 
tation. in several. ways. It allows for a deductive causal theory which greatly reduces 
the complexity of the operator descriptions. It provides, capabilities for reasoning 
with resources, including time. In addition ta this it provides a powerful constraint 
language which allows it to partially specify objects. 

SIPE achieves a high level of efficiency and is the first planner to successfully be 
applied to real-world applications [Wilkins, 1988]. However, even SIPE could benefit 
from advancements in domain- independent pfoblem-solving techuiques-to improve its 
search capability, since, as in previous planners, it remains blind, and is guided to a 
large extent by the user defined operators. 
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TWEAK, developed by Chapman [Chapman, 1987], is a formalization of earlier 
non-linear, planners. Chapman introduces a. sound and complete Modal Truth Crite- 
rion for determining the truth of predicates at any point in a non-linear plan. TWEAK 
is guaranteed to find a solution to a planning problem if one exists— 

The above is by no means an exhaustive review, of earlier -Work on planning; 
just .a selection of some major Systems, chosen to contrast the traditional planning 
research with our research on PABLO. For a good overview of planning systems see 
[Georgeff, 1987, Drummond and Tate, 1989, Allen et al, 1990]. 


3.2 Planning Terminology 

To facilitate the description of PABLO we will-use the TWEAK terminology. In this 
section we present some important definitions. A more extensive description can be 
found. in [Chapman, 1987]. 

A planner is said to be sound if whenever it finds a solution to a planning problem, 
the solution plan is a correct plan for solving the problem. A planner is said to be 
complete if whenever there is a solution. to a planning problem the planner can find 
it. 

At the core of any nonlinear planner is the algorithm for determining the truth of 
predicates at a particular point in the plan. The condition under which a predicate is 
said to hold is known as a truth criterion. TWEAK introduced the first such criterion, 
namely the Modal Truth Criterion. In chapter 9 we introduce a new. truth criterion. 

Two variables are said to codesignate if they are constrained to always refer to 
the same domain object. Similarly, two predicates are said to codesignate if they are 
of the same type and their respective arguments codesignate. For example, On(x,y) 
and On(v t tu) codesignate if x and v as well a sy and w codesignate. - 

Each action in a. plan is an instantiated operator. Each action defines two sit- 
uations, namely the situation immediately preceding the action and the situation 
immedicately following the action. A plan is a partial order of actions with an initial 
situation and a final situation. 

A predicate is Said to be asserted in a Situation if it codesignates with a member of 
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the add list of the action immediately preceding the situation. A predicate is asserted 
in the initial situation if it .codesignates with a member of the initial situation. A 
predicate is denied in a situation if it codesignates with a member of the delete list 
of the action immediately preceding the situation. 

A goal is a pair consisting of a predicate and a situation in which that predicate 
must hold. An action is said to establish a goal if the predicate of the goal is asserted 
in the situation immediately following the action. 

An action is said to clobber a goal if it occurs after the establisher of the goal and 
before the situation in which the goal predicate must be true and it denies the goal 
predicate. 

An action is said to be a white knight if it occurs after a clobberer and before . 
the situation in which, the goal predicate must be true, and whenever the clobberer 
clobbers the goal predicate the white knight establishes it. . 

This brings us to the notions of necessity and possibility. A plan can generally be 
completed in many ways, depending on which temporal and codesignation constraints 
are added to it. If a property of the plan holds in all completions we say it necessarily 
holds. If it holds in some completions we Say it possibly holds. For example, if an 
action clobbers a goal in all completions of a plan we Say that the action necessarily 
clobbers the goal in the plan. If it only clobbers the goal in Some completions of the 
plan, we say the action possibly clobbers the goal. 

3.3 Overview of PABLO 

We can provide more -problem-solving capability in a domain-independent planner 
and thereby shift the burden of problem solving from the user to the planner, by 
analyzing the encoding of the domain before beginning the actual planning process. 

At one extreme, the planner could simply generate the whole search space ahead 
of time, thus trivializing the planning process. This is essentially the approach taken 
in Universal Planning [Schoppers, 1987]. There are several problems in attempting 
this, which we shall return to later in this thesis. 

Another approach is to employ predicate relaxation. By relaxing predicates in 
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the domain, we discover relevant facts about each predicate’s difficulty. This is the 
approach taken by PABLO. 


3.4 Underlying Planning Algorithm 

PABLO uses iterative- deepening _search [Korf, 1985] coupled with TWEAK’s Modal 
Truth Criterion as its underlying planning algorithm. We chose this algorithm pri- 
marily because of its provable correctness and completeness. A breadth first imple- 
mentation requires too much space so an iterative deepening approach was adopted. 
See table 3.1 for a high level description of the algorithm. 

One thing to note about the above algorithm is that for every call to plan we only 
consider resolving one outstanding goal, even though there might be several which are 
unachieved. The reason we can do this, is that if we fail in solving for one-goal, trying 
to solve for any of the other outstanding goals first can have no synergistic effect in 
solving the original goal. This is because the order in which goals are attempted 
is irrelevant, as all possible established are available to the algorithm at any one 
point in the form of operator templates which we can instantiate, into the weakest 
form of an action. Adding constraints to an action can never result in the possible 
establishment of a proposition that could not already be possibly established by the 
action as it was first instantiated. Therefore, if we fail to solve an unachieved, goal, 
we might as well backtrack, since continued Work on other goals will not result in the 
possible achievement of the original goal. 

For reasons of simplicity we have omitted declobbering by white knight in the 
overall control structure. See [Chapman, 1987] for an extensive discussion of the-role 
of white knights in planning. This procedure is complicated and omitting it does not 
affect the completeness of the planner. The reason for this is that final plans always 
have all their variables codesignating with exactly one constant. Therefore, a white 
knight either asserts the proposition, in which case we would use it as an establishes 
or it does not, in which case we can use separation to declobbet_the goal. 
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CallPlan () 

maxdepth *— 1 
loop forever 

plan(0 maxdepth) 
maxdepth <— maxdepth + 1 


Plan (opcount maxdepth) 

g <— any unachieved goal in the plan 
if g then 

for s one of all possible situations that can establish g 
constrain s to be before the situation g.p has to hold 
for p one of all the predicates asserted in s 
add codesignation constraint p « g.p 
declobber(g,s, opcount, maxdepth) 
remove codesignation constraint p « g.p 
remove constraint that s be before the situation g.p has to hold, 
if (opcount < maxdepth) then 

for op one of the possible Operators that , can establish g 
instantiate and insert op into the plan 
constrain op to be before the situation g.p has to hold 
for p one of all the predicates asserted by op 
add codesignation constraint.p « g.p 
declobber(g,s,opcount+l, maxdepth) 
remove codesignation constraint p « g.p) 
remove op from plan 
else print (plan) 
break 


Table 3.1: Base Level Control Structure of PABLO 
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Declobber (g,establisher,opcount,maxdepth) 

Clobberer <— any step in the plan which clobbers g 
if clobberer then 

constrain clobberer to be before establisher 

declobber (g , establisher , op count ,maxdepth ) 

remove constraint that clobberer be before establisher 

constrain clobberer to be after situation in which g has to hold 

declobber(g, establisher ,opcount,maxdepth) 

remove constraint that clobberer be after — 

situation in which g has to hold 

for p one of the possible predicates asserted by 

clobberer which -can deny g.p 

add Codesignation constraint p $ g.p 
dec 1 obber(g, establisher ,opcount,maxdepth) 

remove codesignation constraint p 56 g.p 

else 

plan(opcount,maxdepth) 


Table 3.2: Base Level Control Structure continued. 
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&«4.1 Plan Representation 

PABLO_usfeS a modified version of TWEAK’S modal truth criterion during planning. 
Its plan representation is based on the TWEAK plan representation. In chapter 7 
we .will extend this representation to. include hierarchical operators. In -the name of 
efficiency some extensions have been provided to the operator-representation. Specify 
ically,_preconditions can be specified so as not to be planned for by PABLO, but 
rather, just checked before the application, of an operator. Further, propositions in 
the add list of an operator can be specified to be side effects of the operator and 
should not be considered as possible establishes for unachieved goals. Finally, vari- 
ables of propositions in delete lists can be specified to be global, resulting in a Simple 
form of universal quantification. Each of these extensions is completely optional, but 
can -be used to significantly improve efficiency. 

3.4.2 Relaxation Phase 

Before the planning process begins, PABLO performs a relaxation phase, wherein it 
creates the relaxed definitions for the predicates appearing in the postconditions and 
preconditions of operators. This need only be done once for each domain. 

The User of PABLO specifies the level to which the predicates should be relaxed. 
PABLO creates a relaxation definition for each different type of predicate in the 
domain.. This definition is a relaxation schema and is instantiated every time a 
predicate is instantiated during planning. 

For example, just as was done in the blocks world example of chapter 2* relaxation 
schemas would be created for the predicates Clear(x), Handernpty, Holding(x) and 
Ott(x,y). Then, during planning, a particular predicate instance, Say On(A,B) would 
have associated with it an instance of the relaxation schema for On(x,y) where x has 
been bound to A, and y has been bound to B. 

As Was done in the example presented during the description of predicate relax- 
ation considerable simplification can be accomplished with the use of domain con- 
straints. We will return to the issue of simplifying predicate relaxation expressions in 
chapter 8. 
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3.4.3 Planning Phase 

The general idea during planning is that PABLO first consider the most important 
predicates, and then consider Successively less important predicates. This is accom- 
plished by associating each planning level with a relaxation level, and planning with 
relaxed predicates of that level. At any particular planning level, any predicate whose 
relaxation definition is true at that-level is considered a detail and is not specifically 
planned for. 

The operator Pickup(x), previously discussed, becomes at level 1, 

Pickup(x) 

P : { Clear ( x ) ,H andemp tyj^ } 

D:{Ciear(x),Handempty} — 

A:{Holding(x)} 

When moving down abstraction levels, if newly created subgoals appear in dif- 
ferent sections of the plan, PABLO attempts to achieve them independently. The 
rationale for this being that these predicates were considered “details” at the higher 
level and presumably do not have global consequences. In cases where this assump- 
tion fails, the consequences can, of course, be costly, in terms of computation time. 
However, in our experience the increased efficiency outweighs this risk. 

The above is accomplished by beginning with the initial situation and any instan- 
tiated operators that do not have another instantiated. operator necessarily between 
the initial situation and itself. PABLO plans for any outstanding preconditions or 
goals in this segment of the plan. Once this is done the plan is augmented with 
the next set of instantiated operators which do not have another operator which is 
necessarily before themselves. This process is repeated until the final situation is 
included in the plan. OnCe the full plan has been expanded we can move on to the 
next abstraction level. 

3.4.4 Truth Criterion 

At the core of any planning system is the procedure for determining the truth of 
predicates. Because PABLO has a restricted plan representation, the introduction of 
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abstract predicates complicates this computation somewhat. If arbitrary first order 
Sentences were .alio wed. in the postcondition of operators, the definition for each .ab- 
stract predicate could be included in the initial situation. This rule would then be 
propagated to every situation in the plan. No extra mechanism would then have to 
be provided in the planner to deal with abstract predicates. 

Due to the restriction on-PABLO’s representational Capability we extend the def- 
inition of asserts to include abstract predicates. In a base level system, a predicate is— 
asserted in a particular situation if one of two conditions holds. If the situation is the 
initial situation then the predicate must be contained in the situation description. 
Otherwise, the predicate must be contained in the add list of the operator imme- 
diately preceding the situation. We extend these conditions as follows in order to 
accommodate for relaxed predicates. 

Definition 2 A relaxed predicate P? el is asserted in situation s ijfT(s) I- , where . 
T(s) is the theory consisting of the base level predicates which are necessarily true in 
s. 


The computation of the predicates that necessarily hold in s is then done with 
TWEAK’S modal truth criterion. This criterion is somewhat conservative in deter- 
mining the truth of. abstract predicates but has proven quite adequate in practice. 
We shall later define a new truth criterion which is valid for a more expressive plan 
representation. 

3.5 Examples of planning with PABLO 

3.5.1 Towers of Hanoi 

A well known problem with many inherent abstractions is the Towers of Hanoi prob- 
lem. The operator given to PABLO is the following: - 

Move(x,z) 

P:{SmaUer(x,z),Movable(x),On(x,y),Clear(x),Clear(z)} 

D;{On(x,y),Clear(z)} 
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Figure 3.1: Towers of Hanoi 


A:{On(x,z),Clear(y)} 

See figure 3.2 for a trace of PABLO solving the three disk Towers of Hanoi problem. 
The plan at the highest level of abstraction consists of Move(C,P3). At this level all 
its preconditions are satisfied (Clear^j(C) is satisfied since it can be achieved in two 
steps). „ _ 

Mov«(C,P3) 

Abstraction Level 2 


Move(B,P2) 


- Movt(C,P3) — 
Attraction Level 1 


Move(B.C) 


Move(A,P3) - 

- M6ve(B,P2] - 

■ Move(A,B) - 

> Move(C,P3) . 

. Mo?e(A,Pl) - 

- Move(B.C) ■ 

- Move(A.B) 


Bak Level 


Figure 3.2: Trace of PABLO solving the Towers of Hanoi— 
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When we move down to. the next .abstraction level Clear^ el (C) becomes Clear^(C) 
which is not satisfied in oul. initial state, since we cannot clear C in one step. PABLO 
therefore plans to achieve ClearJ d (C) by adding the action Move(B,P2) to.the plan. In 
doing so it undoes OnJ d (B, C), which PABLO then plains to reachieve, using the action 
Move(B,C). At this point the plan at. the first level of abstraction is complete. since 
all the first level relaxations of the goals and preconditions are satisfied. Planning is 
then completed at the base level using the original predicates of the domain. 

In this case PABLO has discovered and made use of the inherent abstractions 
in the domain. Including the time it takes to generate the relaxation definitions, 
which in this example is negligible, PABLO solves the problem over 100 times faster 
using the abstractions than without using them. In chapter 5 we will present more 
comprehensive empirical results of PABLO. 

3.5.2 Comparison with Other Planners 

All planners of which we are aware, with the exception of ABSTRIPS, would have to 
revert to a full backward search of the state space if given this example. 

Planners using operator abstraction can reason abstractly about this problem only 
if new operators are defined by the encoder of the domain, a. task which might be 
both time-consuming and prone to errors. As we have pointed out earlier, in this 
research we are Striving to provide powerful problem-solving capabilities given simple 
encodings of the domain. 

ABSTRIPS assigns the following criticality values to the predicates in the domain: 
Move(x,z) 

P:{{3}Smaller(x,z),{3}Movable(x),{2}Oh(x,y),{2}Clear(x),{2}Clear(z)} 

D:{On(x,y),Clear(z)} 

A:{Onj(x,z),Clear(y)} 

ABSTRIPS creates only one level of abstraction in this domain. When solving the 
problem, after finishing_the abstract level, the plan consists of one action Move(C,P3). 
Although this is of some aid in developing the plan at the base level it is not as useful 
as PABLO’S hierarchy. 
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ABSTRIPS’s hierarchies are domain-dependent -but problem*- independent. The 
number of different criticality values, and therefore the number of. abstraction levels, 
of ABSTRIPS is constrained by the number of different predicates of the domain. For 
the 4 disk Towers of Hanoi, ABSTRIPS still has Only .one abstraction level, whereas 
PABLO generates 3 abstraction levels. In general, for the n_disk Towers of Hanoi 
problem, PABLO, generates n •*- 1 abstraction levels, whereas ABSTRIPS still creates 
only one abstraction level. 


3.6 Blocks World 


3.6.1 Example Problem 



Inititl State 



Figure 3.3: Blocks World 


This version of the blocks world has two operators: 

PUTON(x,y) TABLEOPR(x,y) 

P:{Clear(x),Clear(y),On(x,z)} P:{Clear(x),On(x,y)} 

D:{Clear(y),On(x,z)} D:{On(x,y)} 

A:{ Clear(z) ,On(x,y ) } A: { Clear(y ) ,On(x , TABLE) } 


The goals are On(A,B), On(B,C), On(C,D), and On(D,E). PABLO begins plan- 
ning at abstraction level 2. See figure 3.4 for a trace of PABLO solving this problem. 

At abstraction level 2 the only goal not satisfied is On^i(C, D). PABLO plans to 
achieve this goal using the action Puton(C,D). All its preconditi ons are Sa tisfied at 
this level of abstraction. 

At abstraction level 1 the precondition ClearJ^C) is not Satisfied so PABLO adds 
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the action Tableopr(B,C) to achieve it. It then reachieves On^j(B, C) by adding the 
action Puton(B,C). 

The plan is then completed at the base level using the base level predicates. . 
Notice that the resulting plan is nonlinear. PABLO solved this problem 130 times 
faster with .the abstractions than without them, including the time to generate the 
predicate relaxation definitions. 


Puton(C,D) 


Abstraction Level 2 


Tableopr(B,C) 


Puton(C,D) 


Abstraction Level 1 


Puton(B.C) 



Bale Level 

Figure 3.4: Blocks World trace. 


3.6.2 Another Example 

The -following example shows the effect of nonlinear plans at higher levels of abstrac- 
tion. See figure 3.5 for an illustration of the problem. 
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Initial State 


Goal 


Figure 3.5: Blocks World Problem. 


The goals of the problem are On(A,D) and On(C,F). A trace of PABLO solving 
this problem can be found in figure 3.6. At abstraction level 2 PABLO satisfies the 
goal On^ d (A,D) by introducing the action Puton(A,D). Its preconditions and the goal 
On^j(C,F) are now satisfied at this level of abstraction. 

At abstraction level 1 the preconditions ClearJ d (A) and ClearJ el (D) of the ac- 
tion Puton(A,D) are no longer satisfied. PABLO at this point inserts the actions 
Tablecpr(x,A) and Tableopr(y,D). There is no reason to order these actions so they 
remain unordered. At this point the first half of the plan is completed. PABLO now 
considers the second half which includes the final situation. This has the effect of 
introducing the goal OnJ el (C,F) to this level. However, this goal is satisfied at this 
level of abstraction so no action is inserted to achieve it. 

At the base level PABLO proceeds in three steps. . The first step considers the 
preconditions to .the two actions Tableopr(x,A) and Tableopr(y,D). PABLO first con- 
siders the precondition On(x,A), which is not Satisfied at the base level-Since x is a 
variable. The variable x is then instantiated with On(B,A). At this point Clear(B) is 
considered since it is not satisfied at the base level. This is satisfied by inserting the 
operator Tableopr(C,B) to the plan. An analogous procedure ensues to satisfy.the pre- 
conditions of Tableopr(y,D), resulting in the insertion of the operator Tableopr(F,E) 

and the. instantiation of variable y with block E. 

At this point this segment of the plan is fully satisfied and the preconditions to 
operator Puton(A,D) are now considered. However, these are all satisfied at the base 
level. Finally, the goals of the final situation are considered. The remaining goal 
On(C,F) is. unsatisfied at the base level* so the operator Puton(C,F) is inserted. Its 
preconditi.Ons.of_Clear(C) and Cleax(F) can be satisfied by constraining the Operators 
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Puton(A,D) 


Abstraction Level 2 



Abstraction Level 1 



Base Level 

Figure 3.6: Nonlinear blocks world trace. 


Tableopr(F,E) and Tableopr(C,B) to appear before Puton(C,F). At this point the 
plan is complete at the base level and PABLO terminates. 

It should be noted that because of the partitioning of the plan at each level into 
self-contained subproblems that the possibility of suboptiiiial plans is introduced. In 
this example, PABLO produces a plan that is one step longer than optimal, since it 
could have satisfied the goal. On(C,F) by the operator Puton(C,F) and at the same 
time satisfied the precondition Clear(B)., thus obviating the need for the operator 
Tableopr(C,B). The reason PABLO did not recognize this possibility is precisely be- 
cause it did not work on the goal On(C,F) until the base level. When the action 
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Tableopr(y,D) was inserted at abstraction level 1, Onl et (C,F) was satisfied so there 
was no need to consider the action Puton(C,F), although it would have resulted in 
a legal plan at that level, of abstraction. This is an example of the trade-off between 
efficiency and optimality that planning with relaxed predicates introduces. 


3.7 Extensions to Predicate Relaxation 

3.7.1 Associating Costs with Operators 

One way in which predicate relaxation can be extended is to associate costs with 
operators and define predicate relaxation levels in terms of particular costs and not 
simply in terms of the number of operators. 

Before we elaborate on this idea, it is important to be aware of two distinctions. 
First, basic predicate relaxation provides a measure of how difficult it will be to plan 
to achieve a certain predicate. It does not provide a measure for how difficult it will 
actually be for the executor of the plan to achieve that predicate. The reason the 
former measure is of value to us, is that it is planning time we are trying to minimize. 
Therefore, it seems reasonable, to concentrate on the predicates for which a simple 
plan does not exist. 

The second .distinction is that predicate relaxation relaxes predicates over unin- 
stantiated operators, i.e. over the operator templates.. Therefore, if we are interested 
in the cost associated With executing an operator it might not be available. -For ex- 
ample, if in our domain we have a drive operator, the cost associated with it will not 
be known until it is instantiated, and might vary considerably. The cost .of driving 
two miles to school is significantly different from driving across. .the country. 

Given these distinctions we can generalize predicate relaxation to relax predicates 
over operator templates with costs associated with them. For example, in a travel 
domain, the highest cost might be associated with the fly operator and -the lowest 
with the drive operator._Then, instead of relaxing predicates in terms of the number 
of operators necessary to achieve them, we relax in terms of cost threshold, e.g. In the 
travel domain* at a particular relaxation level, we would allow more drive operators 
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in. a relaxation of a particular predicate than fly operators. This would have the effect 
of introducing the fly operators into the plan at a higher level of abstraction than the 
drive operators. 

3.7.2 Limit Relaxation Operators 

Another possible extension is to limit the regression of predicates during the relaxation 
phase to a subset of possible operators, thus creating smaller relaxation definitions. 
For example, we might limit the relaxation definitions to only include commonly used 
operators. Also, certain operators might achieve a predicate as a side effect. We might 
limit the relaxation definitions to only those operators which have a predicate which 
is being regressed as a main effect. We will see later, in chapter 8 how this and other 
techniques can be used to significantly reduce the size of the predicate relaxations. 


3.7.3 Relaxation over Hierarchical Operators 

In chapter 8 we will see how we can extend the PABLO operator representation to 
include hierarchical operators. It will then be possible to plan using both types of 
abstractions. We will give an example where it will be desirable to relax predicates 
over hierarchical operators, so there is no longer a one to one correspondence between 
the relaxation level and the number of primitive actions over which we regress. 


3.8 Conclusion 

We have presented PABLO, a non-linear hierarchical planner that automatically gen- 
erates abstraction spaces using predicate relaxation. PABLO is able to solve some 
problems, e.g. Towers of Hanoi, making full use of the abstractions inherent in the do- 
main, something which previous planners could not. The resulting abstraction spaces 
can greatly increase planning efficiency. Predicate relaxation has several advantages 
over ABSTRIPS’s abstraction technique. It is fully automated, it provides a gradual 
abstraction of predicates, and the number of abstraction levels can be tailored to the 
particular problem to be so lved. 



Chapter 4 

Complexity Analysis 


4.1 Introduction 

We might ask what we can gain by using predicate relaxation, Korf [Korf, 1987], 
and later Knoblock [Knoblock, 1990] have shown that planning with abstractions can 
reduce worst-case planning complexity from exponential in the length of the resulting 
plan, to linear in the length of the plan. 

In this chapter we review this work, and then show a complexity analysis of 
planning with predicate relaxation. 


4.2 Previous Work 

One of the first analyses of abstraction was made by Korf.[Korf, 1987]. He was able to 
show that with a properly constructed abstraction hierarchy it is possible to reduce 
planning time from exponential.to linear complexity in the length of the resulting 
plan. However, in the context of traditional planning, the construction used by Korf 
is somewhat non-standard in that it assumes that if there is a path between two 
states at a high-level of abstraction, we automatically know what the path is-at a 
lower level of abstraction. In hierarchical planning this is normally not the case, and 
we must generally plan at the lower level in Order to determine the lower level path. 
The upper ab^txactipn. lexels_provide the lower levels with islands Which guide the 
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planning process. 

Knoblock -[Knoblock, 1990] has analysed abstraction in planning Without this as- 
sumption, showing again that it is possible tojfeduce worst . case planning complexity 
from exponential to linear in .the length of .the final plan. In our analysis of planning 
With relaxed predicates we make use of this result. 

4.3 Complexity Analysis 

4.3.1 Planning at one level 

We will define P(l ) to be the worst case complexity of finding a plan consisting 
of./ actions. In the case of a state-space planner P(l ) = £|_ 0 6‘, where b is the 
branching factor of the state space. This is the model used by both Korf [Korf, 1987] 
and Knoblock [Knoblock, 1990]. However, most planners are plan-space planners 
[Sacerdoti, 1977, Wilkins, 1984, Chapman, 1987], including PABLO. Computing the 
worst case complexity of a plan-space planner is still an open problem, although it is 
likely to be at least exponential in the length of the resulting plan. 

See figure 4.1 for an illustration of a.planner planning hierarchically. The branch- 
ing factor corresponds to the-number of subproblems that each level generates at a. 
lower level. In the figure this branching factor is 2. We refer to this branching factor 
of the abstraction .space as c. If the final plan is of length /, the height of the tree will 
be log c t. 

The complexity of planning using n levels of abstraction, assuming the complexity 
of planning does not. vary with the abstraction level is - 

P.{c) + cP{c) + c 2 P(c) + ... + c ,0S ‘ l P(c) 

where c is the branching factor of the abstraction space. 

However, if we want to compute the complexity of planning with relaxed predicates 
we need to take into account the greater. amount of time it takes to determine the 
trul h of a predicate at a high level of abstraction. 

As we relax a predicate from one level to another we disjoin the predicate with its 
regression through each operator in the domain. There might actually be more than 
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Figure 4.1: Abstraction Space 
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one regressed expression for a particular operator since the predicate might match 
more than one predicate in the .add list. If we haveo operators in the domain, and at 
most s predicates in the add list, each predicate’s regression can consists of at most 
os conjunctions Therefore, if a particular Conjunction consists of p predicates, the 
resulting regression will consist of at most osp conjunctions. 

Notice that as we proceed. with. the-regressions from level to level that the size 
of the conjunctions will increase, assuming we do not perform simplifications. If 
we take d to be the maximum size of any precondition of the operators, then the 
maximum number of predicates at regression level ft is bounded by nd. 1 Note that 
the size of the conjunction might actually be larger since we might generate equality 
and inequality predicates. However, these are simply passed from level to level and 
do not generate any new regressed expressions. Therefore, at relaxation level n the 
number of new. conjunctions generated by regressing a conjunction at level n — 1 is 
bounded by os(n — 1 )d? If at level n — 1 we have Cn_j conjunctions, at level n we 
will have at most os(ti — -l)dc„_i conjunctions. Therefore, at level n, the number of 
conjunctions is bounded by ( osd(n - l)) n . Renaming osd to be k we get (k(n - I)) n . 
For simplicity of exposition we will use the weaker bound of (fen)" which is valid for 
n > 0. For n = 0 there are only individual predicates so the bound is 1. 

Given that the number of conjunctions in a relaxed predicate is bounded by ( kn) n 
we must also establish the complexity of computing the truth of each conjunction. 
We set z to be the maximum number of predicates in a particular situation. In the 
worst case, we might have to try every possible instantiation of each, predicate in a 
coftjunction_of length p which takes z p . Since the maximum number of predicates 
in a conjunction that need to be checked in a situation (i.e. not the equality and 
inequality constraints) is bounded by dn at level ft this becomes s dn . The equality 
and inequality constraints-can each be checked in constant time and their number is 
bounded by 0(ft 2 ). 3 

l In what follows we assume n > 0. 

2 This is only valid for n > 1 

3 This is because at level n, the number ofnew equality constraints generated by regressing a 
conjunction from level n - 1 is bounded by /d(n - 1), where / is the maximum size of the delete list 
of any operator, arid d(n- 1) is the maximum number of nonequality predicates in a conjunction at 
level n - 1. The expression £" =2 fd(i - 1) is bounded by fcn 2 for some k. 
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Therefore, the complexity of computing the truth of an abstract predicate at 
abstraction level n is Q( 2 < * n (A:rt) n ). Simplifying we get 0((z d kn) n ) which is 0((Kn)*) 
for. K = z d k. 

Given this, we can now derive an expression for the complexity of planning with 
relaxed predicates. 

0 (( I<n) n P(c ) + c(I<{n - l))*- l P(c) + ... + c n P(c )) 

We cam Write the above as 

O ^"P(c) + £(/0) J c"-'£(c)j 

Moving the constants out of the sum We get 

o ^p(c)c n (i + t,y<j/cy)j 
The sum. is bounded by 1 + ( gn) n for some g. 

0(P(c)c*(l + (gnr)) 


Simplifying 


0(P(c)(c* + (cgnr)) 


Renaming eg to G and noting that ft is logj we have 

0 (P(c)(c l °^ + ( Glog c l )'**')) 

Which is equivalent to 

0 ( P(c){t + / ,0 * £G /' 0fic '°* c ')) 
Which can be simplified to 
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By noting that G and c are constants and renaming log c G to y this reduces to 

Q _j_ [V+t°9clostl'j 

The expression y - f log c ldg c lgvows very slowly and is therefore very close to being 
a constant, so the complexity has been reduced to nearly polynomial in the size of the 
final plan. It should be noted that if we can guarantee that the.number of conjunctions 
at each abstraction level grows exponentially, as opposed to being bounded by (kn) n , 
we can reduce the planning complexity to polynomial in the length of the final plan. 
As we shall see this occurs in several domains in which we test PABLO. 

Suppose, for example, that we bound the maximum size of any conjunction in 
the relaxation expression to e. Then, the maximum number of conjunctions at level 
n is bounded by £" =0 (ose)‘, where we recall that o is the number of operators in 
the domain and $ is the maximum size of the add list. The maximum number of 
conjunctions in a relaxation expression at level n is therefore bounded by O((ose) ft ). 
We refer to the constant ose as m. Determining the truth of a conjunction in a 
situation with a maximum of z predicates is bounded by z e - which is a constant. 
Therefore, the complexity of determining the truth of a relaxed predicate at level n 
is bounded by Q(rft n ). 

Our expression for the cost of planning now becomes 

0 ( m n P(c ) + cm n - 1 P(c) + ... -fc_c!LP(c)) 

We can write the above as 

Moving the constants out of the sum we get 

0 ^P(c)c n p(m/c)'j 

Solving the sum we arrive at 

O (/>(c)c*((n 1 /c)" + ' - 1 )/((«/«) - 1)) 
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Simplifying 

0 (P(c)(m n+1 - c tt+1 )/(m - c)) 

But n is log c l, so We have 

0 (p(c)(rrt I+,0 * J - c l+l0Ccl )/(tn - c)) 

Which is equivalent to 

0 (P(c)(m/'°* m - c/)/(m - c)) 

Since c is a constant this becomes 

0 (0 ml lod ^ - c/)/(m - c)) 

This reduces to 0(I k ) where k = ittax(l,log c m). 

Therefore, if we can bound the growth of the relaxed expressions to be expo- 
nential in the number of abstraction levels we can reduce planning complexity from 
exponential to polynomial in the length of the final plan. 

4.4 Discussion 

As we have seen, it is possible to reduce exponential planning time to nearly polyno- 
mial in certain circumstances. However, this is only the. case if certain assumptions 
we have made along the. way hold. First, it must be the case that there is no back- 
tracking across abstraction levels. Second, within an. abstraction level, there must be 
no backtracking across the subproblems of that abstraction level- Each subproblem 
must be solved independently of the others. Third, the length of the final plan of 
the abstraction planner must be the same as the length of the plan found by the 
non-abstracting planner. Finally, there must be a uniform branching factor of the 
abstraction space. If any of these assumptions fail, the analysis no longer holds and 
the planning reverts to possibly exponential complexity. Note that these are the same 
assumptions that Knoblock makes in his com plexity analysis [Knoblock* 1990]. 
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As we shall see in the next section, in practice these assumptions generally hold .. 
fairly well for the domains we have attempted. The more amenable a domain is to 
being abstracted, the better these assumptions hold. . 

Furthermore, the complexity of planning grows with the size of y. It is therefore . 
in out interest to reduce the size of the relaxed predicates as much as possible to 
reduce the time to compute their truth value. This can be done by simplifying, as 
well as invoking domain constraints to rule out impossible expressions. Even though 
theoretically the complexity is considerably improved when using relaxed predicates, 
in practice it is important that they not become unwieldy, since this might result in 
an impractically large constant in the complexity formula. We will have more to say 
about this in future chapters. 



Chapter 5 


Empirical Analysis 


5.1 Introduction 

In this chapter we present empirical results of applying PABLO to four domains. 
In each of the domains we compare the performance of PABLO without relaxed 
predicates to PABLO with relaxed predicates. The domains we test PABLO in are 
Towers, of Hanoi, Blocks World, Robot World, and the Eight Puzzle. 

Prom our theoretical analysis we should expect potential gains in planning ef- 
ficiency when applying predicate relaxation. As we shall show, this is indeed the 
case. . 

The data presented in this chapter are from an. implementation of PABLO on 
a Symbolics 3620, under Genera 7.1. It should be noted-that very little Optimiza- 
tion Was performed on PABLO. The numbers Should serve as a. means of evaluating 
the usefulness of predicate relaxation, not as a testament to the ultimate speed of 
planning. 

5.2 Towers of Hanoi 

To show the power of using predicate relaxation in the Towers of Hanoi domain, we 
generated seven problems in the 3 disk problem, each successive problem requiring 
a Solution with a length of one more operator than the previous one. We ran the 
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Figure 5.1: Towers of Hanoi 

problems on PABLO with predicate relaxation and without. A plot of the respective 
planning times can be seen in figure 5.2. 

As can be seen from the graph,, the time it take PABLO to find a solution when 
using predicate relaxation grows linearly with the number of operators in the plan. 
Without the use of predicate relaxation the running time grows exponentially. These 
results conform to our theoretical analysis of predicate relaxation. Notice that each 
of the assumptions of the complexity analysis holds in this example: no backtracking 
across abstraction levels; no backtracking across subproblems; the optimal solution 
is generated; and a uniform abs tr act ion- space branching factor. This results in the 
utility of the relaxed predicates being maximized in this example. 

The Towers of Hanoi is in some sense the canonical example for testing reasoning 
with abstraction, and the gains seen therein are therefore unusually large. Any system 
that reasons with abstractions should be able to show similar gains for the Towers of 
Hanoi. 


5.3 Blocks World — 

PABLO was tested on every distinct four-blocks problem. The optimal solution length 
of the problems range from 1 to 6 steps. We ordered the problems according to the 
optimal solution length, and then averaged the time to solve the problems of each 
length. This was done both with the use of relaxed predicates, as well as without 

their use. The results are presented in figure 5.3 

As can be Seen we see significant speedups in the blocks world as well. It should 
be noted that the optimal solution was not always discovered When using the relaxed 
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Figure 5.2: Running times of PABLO for the Towers of Hanoi (in seconds). 
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Blocks World 



* Without Abstractions 
■O’ With Abstractions 


Figure 5.3: Running times of PABLO for the Blocks World (in seconds). 
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predicates. Out of 223 problems, PABLO generated plans that were One stop longer 
than Optimal when using abstractions 15 times. No other .subop timal plans were 
generated. -As we -have pointed out earlier this is one of the tradeoffs that is made 
when usings abstractions, namely optimality for efficiency. In general, we believe this 
to be a worthwhile tradeoff. 

The. gains in the blocks world were not as spectacular as those in the Towers of 
Hanoi. This is because the blocks world is not as amenable to abstraction as the 
Towers of Hanoi. It is interesting though that significant gains were still observed. 


5.4 Robot Domain 

The third domain tried was the robot world domain similar to that used by STRIPS 
and ABSTRIPS. See figure 5.4 for a typical example. A problem in this domain might 
involve moving the robot from. room G to room A and also push two boxes next to 
each other. A plan for solving this problem might involve opening doors and pushing 
boxes from one room into another. Typical operators for this domain can be found 
in. chapter 8. 


A 

1 □ ' 
B 

c \ 

k 

D 

' ^ □ 

^ rn 

E f 1 — 1 

a 

G 



Figure 5.4: Robot World Domain 

Random problems were generated and ordered according to their optimal solution 
length, as in the blocks world. The times to solve problems of each solution length 
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Robot World 



Operators 

Figure 5.5: Running times of PABLO for the Robot World (in seconds). 

were averaged with and without using predicate relaxation. The results can be seen 
in figure 5.5. 


5.5 Eight Puzzle 

The fourth and final domain in which PABLO was tested was the eight puzzle. This 
puzzle entails sliding eight tiles on a square grid, where there are nine locations. 
Figure 5.6 shows a typical initial state and goal configuration for the eight puzzle. 

As in the previous two domains we ordered the problems according to the optimal 
solution length and averaged the times to solve the problem with relaxed predicates 
and without. The results can be seen in figure 5.7. 
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Figure 5.6: Eight PuZ2le 


5.6 Discussion 

As can be seen from the empirical results, PABLO improved its performance signifi- 
cantly with the use of relaxed predicates. The only drawback was a slight overhead 
on easier problems, and the possibility of suboptimal solutions. 

It should be noted that all the domains in which we have tested PABLO are so- 
.'.ailed toy domains, i.e. they are unrealistically simple. The reason this was .necessary 
is that the underlying planning algorithm used by PABLO, due to its completeness, 
is inherently- slow, and ill suited to real World tasks. As we have explained earlier, 
there are good reasons for using an underlying algorithm that is complete when 
experimenting with abstractions. With a complete planner it is much easier to gauge 
the effects introducing abstractions has on the planner. It is of great interest to see 
if the ideas scale Up to real world problems. 
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Figure 5.7: Running times of PABLO for the Eight Puzzle (in seconds). 




Chapter 6 


Using Abstractions to Achieve 
Reactivity 


6.1 Introduction — 

There is a growing body of research concerned with. tackling the problem of planning 
in unpredictable, uncertain, and time stressed environments. One of the oft cited 
shortcomings of the classical planning approach is that it assumes a benign envi- 
ronment, of which . the planner has complete knowledge,, nothing untoward happens 
during execution and the planner has .virtually infinite time in. which to plan. As. a 
result, most of the new approaches have eschewed classical techniques in favor of more 
radical approaches. We will present a brief overview of some .of the main techniques 
proposed to deal with more complex environments. 


6.1.1 Universal Plans 

Schoppers [Schoppers, 1987] has proposed that rather than plan, an agent should use 
Universal Plans in unpredictable, time Stressed environments. A Universal Plan is 
a function from sensor inputs to actions which computes the appropriate action ta- 
perform in a situation. Thus, the agent has a precomputed action for every possible 
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situation it .can find itself in. One way to store such a universal plan is as a deci- 
sion tree. .Clearly, having such an action cache guarantees very fast response time. 
However, as we shall discuss later there are some problems with it. 


os(t.b) T 

T) at (top) T 

T) MO -OP 
P) -balding <») ? 

T) RAISE 
F) OPEX 
F) el«ar(b) ? 

T) holding (a) ? 

T) ovar(to) ? 

T) LOVER 
F) at (nop) ? 

T) LATERAL 
P) RAISE 

F) [aubplan to CRASP a) 

F) (aubplan to CLEARQFF b] 

Figure 6.1: A piece of a Universal Plan represented as a decision tree 


In figure 6.1 we see a Universal Plan for guaranteeing that On(a,b) holds. The 
plan is represented as a decision tree. Each condition in the tree is tested until a leaf 
is reached. The leaf Specifies the appropriate action to perform. 


6.1.2 Action Nets 

Nilsson has. proposed Action Nets as an architecture in which to implement reactive 
systems [Nilsson et al, 1990]. An action net is a network of units, each of which has 
some inputs (preconditions, a trigger, and a goal), and one output. The output is 
connected to another unit or to a.switch of sortie kind which activates an action in 
the external world. As with the previous approaches an action network guarantees 
very fast response times. Furthermore, there are facilities for dynamically expanding 
the network at run-time, a feature other approaches lack. But, to date, it is not clear 
how action nets might interface with an autamatic.planning system. 


6.1.3 Situated Action Rules 

Agre and Chapman [Agre and Chapman, 1987] have developed Pengi, a program de- 
signed to play the Pengo video game. This game requires quick response times. Pengi, 
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unlike_a Universal Plan, is not purely functional, but retains some state-in its “vi- 
sion” system Even with relatively simple rules, quite complex playing behaviour. 

is achieved by Pengi. For a discussion of. the differences between Pengi and other 
reactive approaches see [Chapman, 1989], 


6.1.4 Subsumption Architecture 

Brooks [Brooks, 1986] proposes the subsumption architecture for controlling an agent. 
The main idea in this proposal is to organize the agent vertically according to levels 
of task-behaviors, with higher levels performing more complex tasks. When a higher 
level completes its computation it can subsume all lower levels. Presumably, higher 
level computations are on the. average more time consuming. When pressed for time, 
the agent uses the result of its lowest level behaviors. However, if given more time, 
one of the higher levels can subsume the lower levels with an action of higher quality. 

This is by no means an exhaustive listing of the approaches proposed for reac- 
tivity. Other interesting ones include [Rosenschein and Kaelbling, 1987, Firby, 1987, 
Drummond and Currie, 1988]. 


6.1.5 Discussion 

We will take the liberty of referring to the above approaches as reactive planners. 
Ginsberg [Ginsberg, 1989] points out .several serious problems with reactive plans. 
The most serious oithe problems is that the size of reactive plans grows exponentially 
with. the size of the domain. Although it remains to be shown, it is likely that the 
domains which A! concerns itself With will be complex enough that reactive plans will 
grow prohibitively large. 

It seems clear that some amount of run-time inference is.necessary for any agent 
to act successfully in an environment. However, it is also necessary to provide some 
mechanisms for reactivity, for situations where there simply is no time for complex 
deductions. 
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6.1.6 Classical Approaches to Reactivity 


Suppose a planner is given the following problem to solve (see figure 6.2 for an illus- 
tration of the problem.) 


A D 

B C 

1' itiil State 



Figure 6.2: Planning Problem 

We are given the following two operators: 

PUTON(x,y) TABLEOPR(x) 

P:{Clear(x),Clear(y),On(x,z)} P:{Clear(x),On(x,y)} 

D:{Clear(y),On(x,z)} D:{On(x,y)} 

A:{Clear(z),On(x,y)} A:{Clear(y),On(x, TABLE)} 

Using the classic non-linear planning method a trace of the plan at various stages 
of development might look as in figure 6.3. 

One notable feature of this trace is that until the final plan is produced the classical 
planner is not aware of any executable actions to perform in the initial state. The 
actions Puton(B,C) and Puton(C,D) are not directly executable in our initial state. 
Should the planner be interrupted at any time during planning with the need to start 
executing immediately it would not have a reasonable action to perform. 

The problem is that the classical planning approaches have invariably been back- 
ward chaining. This is a perfectly reasonable strategy given that in most planning 
domains the branching factor is considerably reduced when reasoning from the goal 
back to the initial state. However, it has the di .wback that until the final plan has 
been developed, there is no guarantee that the plan will actually be applicable in the 
initial state. 

This is one reason traditional planning methods have generally been regarded 
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Figure 6.3: Classic Planning Trace 


as unsuitable for real-time tasks. Besides the reactive planning methods mentioned 
earlier, several other alternatives within the classical planning context have been 
suggested. 


6.1.7 Forward Search 

Some favor abandoning backward chaining plan-space search in favor of a forward 
search of the state space [Washington, 1989]. The advantage of this approach is that 
an executable action is available aS soon as an action has been found applicable in the 
initial state.-Unfortunately, until we encounter the final solution during the forward 
search we have no guarantee that our current sequence of actions will eventually lead 
to the goal. Further, we cannot take advantage of the .least-commitment implicit 
in the non-linear representation of plans. Finally, a forward search, so as not to 
be completely blind, needs a domain-specific heuristic, thereby reducing domain- 
independence. 
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6.1.8 Left Recursive Wedge Planning 

Another approach one can take is that of planning down a left-recursive wedge of 
the partial plan in case of an interruption . [Wilkins, 1988]. The idea is to repeatedly 
expand the leftmost, outstanding preconditions until an action is. -encountered with 
all its preconditions satisfied. In some circumstances this approach might be suc- 
cessful. Unfortunately, the time to plan in this manner is possibly unbounded, since 
interactions might be encountered that necessitate backtracking. 

The method we propose retains the power of partially ordered plan representa- 
tions, but also allows the planner to identify plausible executable actions early in the 
planning process. 


6.2 Reactive Reasoning with PABLO 

The problem we are addressing is that of providing a plausible executable action 
should PABLO, be interrupted before it has formed a complete plan. Ideally, we 
would like to provide as long a sequence of executable actions as possible. 

Toward this end, we can store, along_with each relaxed predicate, the operators 
through which. the predicate was regressed during the relaxation process. Then, 
during planning, when a relaxed predicate is determined to hold in a situation, the 
operator through which the predicate was last regressed is automatically identified, 
e.g. this is the first level relaxation of On(x,y): 


OtlJelOM) 

On(x,y) 

[] 

(y = TABLE) A Clear(x) A 3 z On(x,z) 

[TableOpr(x)] 

(y TABLE) A Clear(x) A Clear(y) A 3 z On(x,z) 

(Puton(x,y)] 


The logical expressions are conditions .under which the predicate should be deter- 
mined to hold. The operators through which the predicate was regressed to arrive at 
the expression-are shown in the right side of the table. In this case, since it is a first 
level relaxation, only sequences having one operator are included. 
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During planning, the relaxation table is examined from top to bottom. When an 
expression is found that. is. satisfied in the current state, the.relaxed predicate is said 
to.be asserted in that state. We also say. the relaxed predicate is grounded in this 
state. This is important because a relaxed predicate that is grounded in a state must . 
have a sequence of operators that is executable in. that state, which guarantee that 
the predicate with hold as a result of their execution. 

6.3 Identifying Executable Actions 

Once PABLO has completed a plan at one level of abstraction, and is working at the 
next lower level, it can utilize the extra information stored along with the relaxed 
predicates that hold .at the higher level, should it be interrupted. 

PABLO chooses a plausible action by examining the preconditions of the earliest 
action(s) of the plan. If one of these actions has all its preconditions satisfied at the 
base level, the action is obviously executable. . 

If no such action exists, PABLO can choose from among the leftmost operators . 
associated with the satisfied predicate relaxations that are grounded in the initial 
situation. All relaxed predicates must be satisfied since the plan was completed at 
the higher level. Furthermore, at least one of the relaxed predicates must be grounded 
in the initial state. To see this note that there must be at least One action such that 
no action is necessarily between it and the final .situation. If all its preconditions were 
satisfied at the base level the action itself would beexecutable. If not, every predicate 
that is abstractly satisfied in the precondition must be grounded in the initial State. 
Any of the actions collected in this manner are executable. 

See figure 6.4 for a trace of PABLO solving the previous example. It.should.be 
noted that PABLO solves the example twice as fast using the predicate relaxations 
than without, since reasoning with the abstractions allows it to prune substantial 
portions of the search space. 

After completing planning at the second level of abstraction the plan consists 
of one operator: Puton(B,C). This is because all preconditions of Puton(B,C) are 
satisfied at this level of abstraction, and because the remaining goals, On(A,B) and 
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Puton(B,C) 
Abstraction Level 2 


Poton(C,D) 


Puton(B,C} 


Abstraction Level 1 



Figure 6.4: Pablo’s Planning Trace 


On(C,D) a.~ also satisfied (at this level of abstraction). See figure 6.5 for a detailed 
description of the planning state at this point. 

As PABLO moves down to the first abstraction level, the goai On(C,D) is no 
longer satisfied since it requires two steps to accomplish. PABLO, grows the plan by 
adding the.operator Puton(C,D) to achieve this goal. Notice that at the first level of 
abstraction all preconditions to Puton(C,D) hold, since D is cleat and block C can 
be cleared in one step. PABLO then completes the plan at the base level. 

Now, suppose PABLO is interrupted after it has completed planning at abstrac- . 
tion level 2. At this level there are three predicates that hold abstractly, i.e. the 
components of their relaxed definitions that are satisfied have non-null operator lists 
associated with them. These are Clear? d (B), Cleaf^,(C), and On^(C,D). 

To see this, examine the second level predicate relaxation of Clear(x). 
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Initial Sot* 


Figure 6.5: Level 2 Plan 


Clear^(ar) 


Clear(x) 

3 y On(y,x) A Clear(y). 

3 y,z On(y,fc) A Clear(y) A On(z,x) 

0 

[Tableopr(y)] 

[Tableopr(y),Tableopr(z)] 


The above, table has been simplified by removing subsumed expressions, e.g. the 
result of regressing Clear(x) through Puton(y,z) is 

3y, z On(y, x) A Clear(y) A Clear(z) 

This expression is not. included in the table since it is .subsumed by the regression . 
of Clear(x) through Tableopr(y). When Clear^ 1 (x) is instantiated in our plan, with 
variable x bound to C, Clear£j(C) becomes: 


Ckar^fC) 

Cleax(C) 

0 

On(D,C) A Clear(D) 

[TableOpr(D)} 

3 y,z On(y,z) A Clear(y) A On(z,C) 

[Tableopr( y),Tableopr( z )] 
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As can be seen from the predicate relaxation definition Clear^ el (C) holds because 
On(D,C) A Clear(D) is true at the base level, and the leftmost regressed operator 
associated with this regressed expression is Tableopr(D). In brief, the three relaxed 
predicates hold in the initial state for the following reasons: 


Clear^C.) On(D,C) A-Clear(D) [Tableopr(D)] 

Clear^j(B) On(A,B) A Clear(A) [Tableopr(A)] 

On^](C,D) Clear(D) A On(D,C) [Tableopr(D), Puton(C,D)] 


The above relaxed predicates are grounded in the initial state. If PABLO is 
interrupted after having completed planning at abstraction level 2, it can choose 
from among the identified action sequences that are executable in the initial state. 
In this case it can propose executing Tableopr(D), Tableopr(A), or Tableopr(D) - 
Puton(C,D). This can be determined as soon as the first level of abstraction has been 
completed - early in the planning process. In this example it is done after only 15% 
of the total planning time. 

6.3.1 Constructing Incomplete Plans 

If necessary, PABLO can construct a substantial portion of the plan, even at this 
eaxly stage. The outline of the algorithm is as follows: 

1. current-plan +— Nil. 

2. current-state *— S, n j tta /. 

3. op-lists *— set of lists of operators associated with the predicates that are ab- 
stractly Satisfied in the plan. _ 

4. op-sequence «— longest tail of the lists in op-lists that is executable in the current 

state 

5. if op-sequence = Nil then op-sequence <— any action in the plan that is exe- 
cutable. If no such action exists, break, returning current-plan. 




66 


CHAPTER 6. USING ABSTRACTIONS TO ACHIEVE REACTIVITY 


6. op-lists <— oplists - op-sequence. 

7. current-plan <— current-plan | op-sequence. 

8. current-state *— S^ of last action in op-sequence. 

9. Goto step 4. 

This algorithm will produce a linear sequence of actions to execute in the current 
state. See figure 6.6 for the incomplete plan constructed using this technique. 


a 


T»bleopr(D) 


Puton(C,D) 


T*bl«spr(A) 


Paton(B,C) 


o 


Figure 6.6: Incomplete Plan 

The plan is almost complete, the only remaining action is Puton(A,B). Once. 
PABLO commits to the first portion of the plan, developing the remaining portion 
can be considerably easier. 

In this case there is little-interaction among the executable alternatives. Therefore, 
the order in which the algorithm places the operator sequences does not matter, and. 
any of the resulting sequences will be a subsequence of a complete, linear plan for the 
problem. However, there are obviously cases where such interactions exist 

For example, given Sussman’s anomaly, presented in figure 6.7 [Sussman, 1973], 
the plan, after planning at the first level of abstraction has been completed, will con- 
sist of Puton(A,B). There are two operator sequences associated With the two pred- 
icates that are abstractly asserted in the plan at this level. The first is Tableopr(C) 
associated with ClearJ el (A). The second is Puton(.B,C) associated with On^(B,C). 

These arehoth executable in the initial State, afld the algorithm has no a priori rea- 
son for choosing between them. Therefore, it might choose to first insert Puton(B,C) 
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A 


B 





Initial State 



Figure 6.7: Sussman’s Anomaly 


into the plan, after, which no more actions are possible. If it inserts Tableopr(C) 
first, then the next sequence inserted will be Puton(B,C), which will be followed by 
Puton(A,B). 

Of course, the only way to discover and resolve conflicts based on such interactions 
is to continue planning. Until a complete plan is produced, we cannot guarantee that 
the optimal action will be chosen by PABLO (or any other planner), should it be 
interrupted. This technique, as opposed to the traditional planning algorithm, pro- 
duces viable alternatives early on in the planning process. Given more time, PABLO 
will complete plans at succeedingly lower levels, thereby resolving conflicts not dis- 
covered at higher levels, and so producing more reliable answers. Our method, in 
effect, provides a primitive anytime algorithm for planning [Dean and Boddy, 1988 1 


6.3.2 Comparison With other Classical Approaches 

Unlike a forward search of the state space, PABLO can take advantage of the ’east- 
commitment implicit in non-linear plans. Rather than being committed to one path 
in the state space at any_one time, the partial order of actions represents a set of 
possible paths that are currently valid. In NOAH, the non-linear representation was 
found to be successful enough that no backtracking was deemed necessary. 

Furthermore, wher- it is interrupted, its choice for a plausible executable action 
is derived from a complete abstract plan, which provides a global constraint on this 
action. An interrupted forward state-space Search on the other hand, can only provide 
local constraints on its choice of executable actions. 



68 


CHAPTER 6. USING ABSTRACTIONS TO ACHIEVE REACTIVITY 


Unlike the technique of continuing planning down the leftmost wedge of the plan 
after an interruption, Our approach .requires only a bounded computation time to .pro- 
duce an executable action after an interruption. To. see this, note that the executable 
actions are automatically identified after planning at the highest level of abstraction 
has been completed. 

6 A Comparison to Reactive Plans 

The trace of the relaxation of a predicate can be thought of as a reactive plan for 
achieving that predicate. See figure 6.8 for an illustration of the definition of the 
On^ d (a:,y) predicate as a reactive plan. Notice .that some predicates in the reactive 
plan are not further regressed, this is because these are preconditions to the operator 
that we do not wish to plan to achieve, but rather just check that they hold. These 
predicates. are specified-in the operator definitions given to PABLO. During planning, 
when a relaxed predicate is determined to hold, the path through -the reactive plan 
that will lead to the establishment of the predicate, is automatically identified. 

Our technique is a method for handling these small reactive plans. We believe that 
this is a more promising approach to reactivity than constructing large, unwieldy re- 
active plans which risk succumbing to space restrictions very quickly. Each individual 
plan is restricted in size and can be reused by the planner on different instantiations 
of the same predicate. 

Each reactive plan in our system has a clear purpose, namely to achieve a particu- 
lar predicate. Unlike other reactive planning techniques which must construct a new 
reactive plan for each combination of goals encountered (modulo some parameters to 
the reactive plan), PABLO can re-utilize the reactive plan definitions for any goals 
specified in the domain. 

If our domain is large enough we risk creating abstraction definitions that are too 
large, although they will always be considerably smaller than reactive plans created for 
entire domains,, since we are only considering reactive plans for individual predicates. 

With PABLO, we can extend the planning method to restricted reactive plans, 
e.g. allow only commonly encountered conditions in the relaxed definitions. Although 
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FigureJ3.8:_ Reactive plan for On^i(x,y) 

this reduces the number of abstractions identified at the higher levels, each predicate 
can be more quickly identified to hold abstractly. PABLO is robust in the sense that 
if a predicate is not deemed to hold abstractly, it can plan to achieve it. This is 
something systems which rely solely on reactive plans cannot do. 


6.5 Conclusion 

Using the method presented in this chapter, we can utilize predicate relaxations to 
produce a plausible executable action should PABLO be interrupted before the final 
plan has been completed. The only, requirement foi identifying a plausible action is 
that planning have been completed at the highest abstraction level. This happens 
early-in the planning process. 

The method can be viewed as an anytime algorithm for planning. During planning, 
harmful interactions are identified and resolved as PABLO plans at succeedingly lower 
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levels of abstraction, thus increasing the quality of the response in case of interruption. 

Each automatically generated abstraction is actually a small reactive plan for 
achieving that predicate. PABLO provides a mechanism for combining these small 
reactive plans dynamically. Besides the inherent advantages of reasoning abstractly, 
we can also achieve some measure of reactive behavior, should the planner be inter- 
rupted during planning. We believe this is a more promising approach to reactivity 
than the reasoning with large, unwieldy reactive plans. 



Chapter 7 

Operator Hierarchicalization 


7.1 Introduction 

The abstraction of. operators has been a prevalent theme in the history ^of planning. 
Researchers early realized the value of being able to define abstract operators in 
terms of other, less abstract, operators. Doing so allows the planner to ‘‘jump” from 
one part of the state Space to another with one step, potentially bypassing much 
planning. However there have been Some problems with the proposed abstraction 
representations which we hope will become apparent. 

7.1.1 MACROPS 

The first Use of what we will label “hierarchical operators” is in STRIPS, with the 
MACROPS extension [Fikes and Nilsson, 1971]. As the name suggests, this extension 
allowed STRIPS to learn and use macro operators, for significant computation time 
savings. 

STRIPS would store a plan in a triangle table and then apply a procedure to “lift” 
a generalized MACROP from the triangle table. 

MACROPS is interesting for several reasons. It is the first use of hierarchical 
opetators-in planning, and it is an example of a planner learning abstractions to 
speed up problem solving. An example is shown in figure 7.1. 


7i 
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Figure 7.1: A STRIPS MACROP 

7.1.2 SOUP operators 

With NOAH came the next major advance in hierarchical operators. Operators in 
NOAH were defined in SOUP (Semantics of User’s Problem) code, which, allowed 
for quite general operator definitions. With NOAH came also the term hierarchical 
planning. See figure 7.2 for an example of a NOAH operator. 

The SOUP code in the body of the operator provided instructions to NOAH for 
how an operator should be expanded to the next level of detail. As has.heen. pointed 
out by several researchers,, a NOAH operator is not necessarily hierarchical. For 
example, in the blocks world, each operator is defined only in terms of a primitive 
operator and its preconditions. When combined with the NOAH methodology of 
producing a plan by expanding all the expandable operators in a plan and then 
critiquing it, a particular ordering in the expansion of goals was imposed. 

There is one major drawback with defining operators in this manner. Sacerdoti 
states [Sacerdoti, 1977]: 
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(PUTON 

(QLAttBDA 

(ON -X -Y) 

(* Clear fX and SY, then put 
tX on SY) 

(PANO 

(PCOAL (Clear IX) 

(CLEARTOP IX) 

APPLY 
(CLEAR) ) 

(PGOAL (Clear SY) 

(CLEARTOP SY) 

APPLY 
(CLEAR) ) ) 

(PGOAL (Put SX on top of SY) 

(ON SX SY) 

APPLY NIL) 

(PDENY (CLEARTOP SY)))) 


Figure 7.2: A NOAH operator 


The most serious deficiency in the current system is its lack of aware- 
ness about the auxiliary computations specified in the procedural .semam 
tics (the SOUP code) of a task domain. The procedural net representation 
lets the system be. aware of the goals and subgoals that the planner has 
decided to tackle, but it does not preserve any information about the 
computation that resulted in those decisions. 


Because the semantics of NOAH operators are opaque to NOAH their usefulness 
is limited. Primarily, the operators must be defined by the user; it would be very 
difficult for NOAH to generate new ones. Furthermore, only a minimal amount of 
error checking can be done by NOAH, which leaves an additional burden on the user 
of the system. 
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7.1.3 Procedural Net Operators 

The state of the art in hierarchical operators is found in SIPE [Wilkins, 1988]. SIPE 
solves the problem, of semantic Opaqueness by defining the plots of hierarchical oper- 
ators in the same language as that used for its internal procedural net representation. 
This provides a powerful language in which to define hierarchical operators. 


Operator: Putoa 

Arguments: blockl, objectl Is Not blockl; 
Purpose: (On blockl objcctl); 

Plot: 

Parallel 

Branch 1*. 

Goals: (Clear objectl); 

Branch 2: 

Goals: (Clear blockl); 

End Parallel 

Process 

Action: Puton-Primitive; 

Arguments: blockl ( objectl; 

Resources: blockl; 

Effects: (On blockl objectl); 

End Plot End Operator 


Figure 7.3: A SIPE operator 


Defining hierarchical operators in terms of a procedural net facilitates not only 
the design of the planner, in that another language need not be added on top of the 
existing plan language, but also error checking and the learning of new operators. 
Although SIPE does not currently, learn new operators, its operator representation 
language provides the infrastructure for transferring knowledge in plan form into 
operator form. 
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7.1.4 Formalized Reduction Schemata 

In his thesis [Yang, 1989], Yang formalized.a version of hierarchical Operators similar 
to t hose-found in SIPE. He defines action templates, which consist simply of precondi- 
tions and effects. He then defines a set of action reduction schemata each of which is a 
function that takes an action template as input and returns a Set of partially ordered 
action templates, with protection intervals between them. The reduction schemata 
are analogous to plots in SIPE operators. 

7.1.5 Problems with Hierarchical Operators 

Incorrect Specification of Operators 

One problem with the current definition of hierarchical operators is that they might be 
incompletely or inaccurately specified, i.e. their preconditions and effects might not 
reflect the actual preconditions or effects of the operator after it has been expanded. 
One possibility is that the user simply encodes the wrong effects in the postconditions 
of an operator., e.g. the encoder of the domain might include a proposition in the 
add list of a hierarchical operator that is not added by any action in its expansion. 

However, even if the encoder is very careful and only includes effects that are 
guaranteed to hold after the expansion of a hierarchical operator, there are still po- 
tential problems. This is because a hierarchical operator might have several possible 
expansions, some of which result in Some proposition holding, and others whic h result 
in the proposition not holding. 

Hierarchical Promiscuity 

A related, though slightly different problem, is one that Wilkins [Wilkins, 1988] terms 
hierarchical promiscuity. The problem occurs when operators are described abstractly, 
using different sets of predicates for each level of abstraction. It is possible then, when 
the planner expands different parts of the plan at different rates, that one part will 
be referring and modifying predicates at a much lower level than a part of the plan 
previous to it. In such situations it is possible that potentially harmful side effects at 
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the lower level of abstractions will not be recognized until much later in the planning 
process, resulting in unnecessary planning. 

There have been several solutions proposed for this problem. SIPE has a mech- 
anism for enforcing, an ABSTRIPS-like ordering in expanding the operators down 
to different abstraction levels. Further, it allows the specification of special delaying 
operators, which cause SIPE to refrain from planning for certain goals until some con- 
ditions have been satisfied in it? state. Yang [Yang, 1989] proposes a solution wherein 
syntactic restrictions are computed for operators ahead of time which guarantee that 
harmful side-effects will not occur after expansion of an Operator. 

Unrecognized resolutions . 

However, even when the operators are specified- completely accurately there are still 
potential problems. For example, take the problem in figure 7.4 proposed by Yang 
[Yang, 1989]. Part (a) represents a plan with two actions, each of .which clobbers the 
other action’s precondition. There is seemingly no legal ordering to the two action. 
However, when the plan is further expanded in (b) each action has become two actions 
and a legal ordering exists among the resulting four actions. - 

This is an instance of a “Double Cross” described by Sacerdoti [Sacerdoti, 1977]. 
In this situation a seemingly unresolvable conflict at one point in the plan can be 
resolved when the plan is further expanded. Thus, a planner using the traditional 
hierarchical operator specification might give up and backtrack when plan (a) is 
encountered, missing a potential solution. 

Incompleteness 

Another problem, less serious, but still interesting from a theoretical point of view is 
that of completeness. There has as yet not been a planner proposed which supports 
hierarchical Operators and yet is complete. The reason this is not such a serious prob- 
lem is .that completeness in any planner implies intractability. Hence, any planner of 
practical value must make use of some sort of heuristic information to cut substantial 
portions of the search space. However, from a theoretical point of view, a complete- 
ness result provides a useful point of reference and starting point for discussing in 
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Figure 7.4: (a) A plan with seemingly unresolvable conflicts (b) Resolution of conflicts 
after reduction. 

what ways a planner deviates from a compl ete alg orithm. 

7.2 Generalizing STRIPS- style operators 

Although it allows for the formalization of restricted non-linear planning, the STRIPS- 
style operators used by TWEAK fail to capture one important aspect of most major 
non-linear planners, namely their hierarchical nature. It is no accident that NOAH, 
SIPE, etc. are generally referred to as hierarchical planners - this has traditionally 
been their defining characteristic and a source of much of their power. 

In this chapter we present a generalization of the STRIPS-style operators that 
captures much of the hierarchical nature of previous planners. We then demonstrate 
a control strategy for reason wig with this generalized representation that guarantees 
a limited form of completeness. 
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7.3 Representation 

We generalize STRIPS-stvle operators by defining hierarchical operators to.be dis- 
tinguished plans. An operator is simply a plan which has been deemed useful enough .... 
to. store and use in problem solving. Obviously, STRIPS-style operators are special 
cases, namely they are plans limited to one action and_possibly some codesignation 
constraints. More formally: 

Definition 3 (Operator) An operator is a triple (0,T,C\ where O is a set of ac- 
tions, T is a set of temporal constraints, and C is a set of codesignationjconstraints. 

An operator is very much like a plan. A primitive operator is a specialization of 
operator. 

Definition 4 (Primitive Operator) A primitive operator is an operator fO,T ,C) 
where O is a unary set consisting of one action, T is an empty set, and C is a set of 
codesignation constraints. 

Befo re an operator (0,T,C) can be used in a plan it must be instantiated. This 
is done by creating a new operator (0',T',C') where 

• O' is & copy of O where every variable of every-action of O is replaced with a 
new variable in the corresponding action of O'. 

• T' is a copy of T where every action in a temporal constraint is replaced by its 
corresponding copy. 

• C' is a copy of C where every variable in the codesignation constraints is replaced 
by its corresponding copy. 

After instantiating an operator we need to insert it into a plan. Given a plan 
P (G?p, Tp, Cp, Sinitiah S final) and an instantiated operator ( 0 0 ,T 0 ,C 0 ) the new plan 
created by inserting . the instantiated operator is {0 P C0 0 , T P UT 0 , C P UC 0 , «S,„,n a /i <S/»tia/)- 
In figure 7.5 we give a graphical illustration of two hierarchical operators. In the 
figure, one of the hierarchial operators has been chosen to be inserted into the plan. 
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Figure 7.5: Diagram of Hierarchical Operators 


This definition of hierarchical operators readily lends itself to the creation of new 
ones. The planner can create new operators simply by storing old plans which it 
deems to be potentially useful. Of course, only some plans will be particularly useful 
so the planner must have some means of deciding on the usefulness of particular 
hierarchical operators. 


7.4 Hierarchical TWEAK 

An important feature of our hierarchical operators is that at any point during plan- 
ning,. our plan is always composed solely of primitive actions. This feature allows us 
to use the TWEAK modal truth criterion to determine the necessary truth of goals 
and preconditions. 

However, we need to extend TWEAK’s control strategy to include hierarchical 
operators. As it turns out we only have to make a few minor changes to the algorithm 
in order to handle abstract operators. 
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7.4.1 Selecting Hierarchical Operators 

One important issue we need to address is that of selecting hierarchical Operators for 
instantiation into a plan. .Previously, anoperator was selected on .the basis of whether 
any proposition in its add list could possibly codesignate with the proposition which 
needed to be achieved. Now that each operator is composed of a partiaLorder of 
operators we need to decide what .criteria to use when selecting an operator. 

One solution is to choose only hierarchical operators for which the proposition of 
the current goal is possibly asserted in a hypothetical situation placed after all the 
primitive actions in the operator. Although this solution is intuitively appealing it is 
somewhat restrictive. Figure 7.6 illustrates a situation where we should have chosen 
a hierarchical operator even though, as a unit, it does not possibly assert the current 
goal. . 

In figure 7.6 if we need .an action to achieve the precondition p of the plan in part 
(a), we can choose the hierarchical operator .A and insert it into the plan as shown in 
part (b) of the figure. Note that we should choose operator A even though p is not 
possibly true after its application. 

The solution we have chosen is to choose an operator for instantiation into a plan 
if any of its actions possibly asserts the current goal, even though one its later actions 
might deny it. Using this approach, Hierarchical TWEAK would .have chosen to 
expand operator A because its subaction A\ possibly asserts the goal proposition. 

Hierarchical TWEAK is then simply TWEAK augmented with the hierarchical 
operator selection strategy outlined above, plus facilities for properly instantiating 
and inserting hierarchical operators. 


7.5 Differences with Other Hierarchical Opera^ 
tors 

Incomplete Specification of Operators 

The problem of incorrectly specifying preconditions and effects of hierarchical oper- 
ators is not an issue since our operators do not have explicit preconditions or effects 
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Figure 7.7: Yang’s problem revisited 

Completeness 

An interesting. question to consider is whether completeness is preserved with the 
new hierarchical operators. Clearly, if we retain as a condition that every primitive 
operator of the domain be represented by one hierarchical operator, the new algorithm 
will remain complete, since any plan that would have been found without hierarchical 
operators will Still be discovered. 

However, if we relax this condition, we cannot guarantee completeness in the 
sense that if there exists a plan composed of primitive operators, one -will be found 
using only hierarchical operators. One obvious counterexample is the case where the 
only final solution consists of exactly one primitive action, but every operator in the 
domain consists of at least two actions. 

We can, though, guarantee a weaker form of completeness. Namely, if a plan that 
is a solution to a problem can be fully partitioned into sets of actions, each set being 
an instantiation of a hierarchical operator, Hierarchical TWEAK will discover it. We 
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will refer to such a partition as a hierarchical partition. 



Figure 7.8: Partition Graph 

This is most clearly explained in graph theoretic terms. We will think of the 
partitioned plan as a graph, where one partition points to another if the former 
contains a primitive action which establishes a proposition that is a precondition for 
an action of the latter. Further, a partition points to. the final situation if some action 
in the partition establishes a proposition in the final situation. We will refer to this 
graph as the p artition graph. 

Definition 5 (Spanning Property) A hierarchical partition of a plan satisfies the 
spanning property iff there is a path from every partition to the final situation. 

Lemma 7.5.1 A hierarchical partition satisfying the spanning property has some par- 
tition that can be removed, such that the resulting plan stitl satisfies the spanning 
property. 

Proof (by contradiction): 
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Assume lemma 7.5.1 does not hold. Then it must be the case for every partition- 
that removing it results in some partition no longer .having a path to the final situ* 
ation. This implies that for every_partition p\ there is some partition p 2 that points 
to it such th&t all the paths from p 2 to the final situation contain pi. We will refer 
to partitions such as p 2 as. dependent partitions. 

Now, we star* at the final situation. We choose any partition that establishes 
a proposition in the final situation. We mark it. We then traverse the partition 
graph, by choosing a partition that is dependent on the current one. We mark it 
and repeat the procedure. Note that we cannot revisit a marked partition since we 
already know there is a path from every marked partition to the final situation that 
does not contain any unmarked partitions. Therefore, a marked partition cannot be 
dependent on an unmarked one. Since the graph is finite, it must be the case that 
for some partition we will be unable to find another partition that is dependent on 
it. But this violates our assumption that such a partition exists for every partition. 
Therefore lemma .7.5.1 must-hold. □ 

Lemma 7.5.2 Every hierarchical partition of a plan generated by TWEAK satisfies 
the spanning property. 

Proof: 

Define the temporal distance of a primitive action to be the longest path from the 
primitive action to the final situation over the temporal constraints in the plan. 

Define the temporal distance of a partition to be the minimal temporal distance 
of its primitive actions. We prove that there must be a path from e''ery partition to 
the final Situation by induction on the temporal distance of paititions. 

Base step: In the null plan there are no partitions and therefore the lemma holds 
trivially. In all -other plans, if a partition’s temporal-distance is 1 it must be the 
case that one of its primitive actions establishes a proposition in the final situation 
(a primitive action-must be necessarily before any-situation in which it establishes a 
proposition), or. it would not have been inserted by TWEAK. This means that the 
partition points t.o4he final situation and therefore there is a path from the partition, 
to the final situation. 
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Figure 7.9: Temporal Distance 

Induction step: Assume that for every partition with a temporal distance of n — 1 
or less there is a path in the partition graph to the final situation. We will prove 
that there is a path in the partition graph for all partitions with a temporal distance 
of n. In the partition there must be some primitive action such that its temporal 
distance is n. Furthermore, it must be the establisher of a proposition of either the 
final situation or the precondition of another primitive action. In the former case it 
is obvious that there is a path from the. partition to the final situation. In the latter 
case it must be the case that the other primitive action is part of a different partition 
which must have a temporal distance of n — 1 of less. But by the induction hypothesis 
there must exist a path from.that partition to the final situation. Therefore, there is 
a path from the original partition to the final situation. □ 

We want to prove that every plan that is a solution to a problem and can be 
legally partitioned can be constructed by Hierarchical TWEAK. Since TWEAK is 
complete it can construct every such plan. But by lemma 7.5.2»^&ery such plan must 
satisfy the spanning property. Therefore, it suffices to show: 

Theorem f.S.S (Limited Completeness) If a plan can be fully partitioned into h 
mutually exclusive sets of actions, each sei being an instantiation of some hierarchical 
operator, such that the spanning property holds, the Hierarchical TWEAK algorithm 
will construct it. 

Prodf (by induction on n, the number of partitions): 
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Base step: n = 0 

If the plan can only be fully partitioned into 0 partitions then the plan must be 
the null plan. This is the plan that Hierarchical TWEAK begins with. 

Induction step: 

Assume the-theorem holds for plans that can be partitioned into n — 1 hierarchical 
operators such that the .spanning property, holds. We will show it must hold for all 
plans that can be partitioned into n hierarchical operators such that the spanning 
property holds. 

By lemma 7.5.1 there must be some partition that can be removed from the plan 
such that the spanning property holds in the resulting partitioning. But because this 
is a plan of n — 1 partitions and the Spanning property holds, the induction hypothesis 
guarantees that hierarchical TWEAK, will construct it. It now remains to be shown 
that the removed partition would be added. But since every partition is, by definition, 
an instantiation of a hierarchical operator, and since the spanning property holds, it 
must be the case that there is some primitive action of the partition that estab- 
lishes a proposition of a situation outside the partition. Therefore, since Hierarchical 
TWEAK, in its complete breadth-first search, inserts all hierarchical operators which 
have some primitive action which can possibly establish some unachieved proposi- 
tion in the plan, the hierarchical operator corresponding to the partition would also 
be inserted into the plan. Since the TWEAK declobbering strategy guarantees that 
all possible alternatives will be constructed, temporal and Codesignation constraints 
would be added to the plan, such that one of the resulting plans was identical to the 
original plan. □ 

Therefore, if.a solution exists to a problem, Such that the resulting plan can be 
partitioned into n hierarchical operators, then Hierarchical TWEAK Will find it. 

Shuffling of Operators 

Another, more subtle difference tvHh the other hierarchical operator formalisms is that 
using the traditional hierarchical operators, once a hierarchical operator is inserted 
into a plan, its expansions must satisfy its higher level temporal constraints. For 
example, in figure 7.10 we have the expansion of a SIPE hierarchical operator. 
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Figure 7.10: SIPE plan example 

In this example, all the subactions of action B must be placed after all the sub- 
actions of action A and before all the subactions of action C. Using our definition 
of hierarchical operators it is possible that the plan could expand such that some of 
the subactions of an action could be shuffled with some of the subactions of. another 
action, e.g. as we saw earlier, figure 7.6 provides an illustration of this. This feature 
provides Hierarchical TWEAK with more flexibility when expanding a plan. 

7.6 PABLO Implementation 

We have extended, the PABLO operator representation to include hierarchical oper- 
ators. We present an example, that should help clarify the usefulness of hierarchical 
operators. We will use the robot domain used in STRIPS and ABSTRIPS. Before 
presenting an example problem we define two hierarchical operators. 

Operator 1 allows the robot to get to an adjacent room even when the door is 
closed. Operator 2 is similar and allows the robot to push a box into another room 
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Figure 7.11: Hierarchical Operators fo' the Robot Domain 
when the door is closed. 

We will demonstrate .PABLO on the problem depicted in figure 7.12. 

See figure 7.13 for the final plan. PABLO solves the problem considerably faster 
when using the hierarchical operators than it does without. 

7.7 Retaining useful plans 

One useful consequence of our planner reasoning with hierarchical operators whose 
semantics are perspicuous to itself, is that learning new hierarchical operators in con- 
siderably facilitated. In fact, to generate a new hierarchical operator the planner, 
need only copy a current plan and store it along With its other operators. Of course, 
some criteria must be applied to decide which operators might be generally useful, 
and which might not. 
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Figure 7.12: Robot Domain Problem, (a) Initial State, (b) Goal State. 


7.7.1 Towers of Hanoi 


How can hierarchical operators be learned and used effectively in planning? Here is 
one possible scenario in the Towers of Hanoi domain. The strategy of the planner is 
to solve.progressively more difficult problems within the domain. 

Suppose the planner is given the three, disk Towers of Hanoi problem. First, 
it orders the subgoals independently in terms of difficulty. One way this could be 
done is by using the predicate relaxation definitions and applying them to the three- 
goals. The resulting order would then be (1) Onpeg(A,P3), (2) Onpeg(B,P3), (3) 
Onpeg(C,P3). 1 The planner would then plan first for achieving 0npeg(A,P3). This 

‘Note the different flotation from before, Oflpeg(x,y) instead of On(x,y). This change was made 
to facilitate the exposition of this particular approach. 
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is trivial and does not generate a new operator. It would then plan to achieve the 
conjunction of (1) and (2). This would be slightly more difficult and would gener- 
ate the plan Move(A,P2)-Move(B,P3)-Move(A,P3). This plan would be stored 
away for further use. But how should it be generalized? Clearly, one should not just 
convert all the constants in the plan into variables. 

One possible. generalization mechanism is to consider the bulk preconditions of . 
the plan (Drummond and Currie, 1988]. Thebulk preconditions are those that must 
hold in the state where the hierarchical operator will be applied to guarantee that 

every primitive action in the operator is applicable. If these preconditions have_ more. 

than One consistent instantiation they should be generalized. 

In the plan for solving goals (1) and (2) the bulk preconditions and their possible 
instantiations are as follows: 
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Ciear(dl) 

Clear(A) 

Clear(A) 

Onpeg(dl,pl) 

Onpeg(A,Pl) 

Onpeg(A,Pl) 

Movable(dl) 

Movable(A) 

Movable(A) 

0npeg(dl,d2) 

Onpeg(A,B) 

Onpeg(A,B) 

Onpeg(d2,pl) 

Onpeg(B,Pl) • 

On P eg(B,Pl) 

Movable(d2) 

Movable(B) 

Movable(B) 

Onpeg(d3,p2) 

Onpeg(BASE2,P2) 

Onpeg(BASE3,P3) 

Smaller(dl,d3) 

Smaller(A,BASE2) 

Smaller(A,BASE3)_ 

Clear(d3) 

CIear(BASE2) 

Clear(BASE3) 

Onpeg(d4,p3) 

Onpeg(BASE3,P3) 

Onpeg(BASE2,P2) 

Smaller(d2,d4) 

Smaller(B,BASE3) 

Smaller(B,BASE2) 

Clear(d4) 

Clear(BASE3) 

Clear(BASE2) 


There are two possible instantiations of the bulk preconditions in the initial state. 
In these instantiations p2, p3, d3, and d4 are instantiated to different values. The 
variable p2 is either instantiated to P2 or P3, p3 is either instantiated to P3 or P2, 
d3 is either instantiated to BASE2 or BASE3, and d4 is either instantiated to BASE3 
or BASE2. The fact that only these variables vary suggests that only these variables 
should be generalized. 

After generalizing them the plan for solving goals (1) and (2) becomes Move(A,x) 
- Move(B,y) - Move(A,y). Finally, the planner proceeds to solve goals (1), (2), 
and (3).. The actual, solution trace can be seen in figure 7.14. The planner uses the 
newly generated hierarchical operator for moving the two top blocks twice, once to 
move them to the middle peg and finally to move them to the last peg. 

The key to this approach is first to order the goals in terms of difficulty. Predicate 
relaxation provides a mechanism for doing so. Secondly, using the initial situation 
to determine the possible instantiations of the bulk preconditions of the generated 
hierarchical operator, to decide which variables should be generalized. We believe 
this to be a promising approach to automatic operator abstraction, but more work 
remains to be doneJn this area. 
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Figure 7 4: Operator Abstraction Solution Trace 

7.8 Conclusion 

We have presented an elegant definition of hierarchical operators which overcomes 
marly of the problems associated with earlier hierarchical operator definitions, and 
proven that it is possible to guarantee limited completeness when using them in 
planning. A mechanism for using hierarchical operators has been incorporated into 
PABLO. 




Chapter 8 

Combining Abstraction Methods 


8.1 Introduction 

In this chapter we demonstrate several ways to use state abstraction and operator 
hierarchicalization simultaneously for effective problem solving. Recall that PABLO - 
achieves a form of state abstraction through predicate relaxation and operator hier- 
archicalization through the use of hierarchical operators. 

8.2 Robot World Example 

In this first example we will use predicate relaxation and hierarchical operators in the 
manner in.which they have been presented. We will see later how predicate relaxation 
can be extended to include relaxation of predicates over hierarchical operators. . 

We will present an example in some detail and- describe the problem solving that 
PABLO does to solve it. The domain of the example is the familiar robot world, with 
rooms, doors, boxes. In addition to. these we also include keys and add the operators 
to lock and unlock doors. Furthermore, keys can be dropped into boxes, in which 
case they can no longer be retrieved by the robot. 

In the following Operator descriptions some arguments to predicates in some of 
the delete-lists are preceded by a $. These variables are special, in. the sens:; that 
they are treated as global variables. For example, if there is a predicate P($l) in a 
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delete list, and two predicates R(A) and P(B) in the situation description, then both 
predicates will be deleted from the situation description, instead of just one. These 
are the-operators used: 

Pickup«key(R,k) 

P:{Type(k,Key).Nextto(R,k),Graspable(k)} 

D:{Nextto(R,k)} 

/u{Hoiding(R,k)} 

Put-key-in^box(R,k,b) 

P:{Type(k,Key),Type(b,Box),Nextto(R,b),Holding(R,k)} 

D:{Holding(R,k),Graspable(k)} 

A:{In(k,b)} 

Goto-obj,ect(R,o) 

P:{Type(o, Object), In:oom(R,rx),Inroom(o,rx)} 

D:{Nextto(R,$l)} 

A:{Nextto(R,o)} 

G’oto-do6r(R,d) 

P : { Type(d,Door) ,Inroom(R t rx), Connects (d,rx,ry) } 

D:{Nextto(R,$l)} 

A:{Nextto(R,d)} 

Gothru-door(R,d) 

P:{Type(d, Door), Irroom(R,rx),Connects(d,rx,fy),Status(d, Open)} 
D:{Nextto(R,$l),Inroom(R,rx)} 

A:{Inroom(R.ry)} 

Open-door(R,d) 

P : { Type(d,Door-) ,Nextto ( R.d) ,Status (d , Closed) } 

D :{ Status ( d , Closed ) } 

A: {Statu$(d,Open)} 

Close-door(R,d) 

P:{Type(d, Door), Nextto(R,d),Status(d, Open)} 

D: { Status(d,Open) } 


8.2. ROBOT WORLD EXAMPLE 
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A:{Status(d, Closed)} 

Lock-door(R,d,k) 

P:{Type(d, Door), Nextto(R,d),Status(d, Closed), Holding(R,k),Type(k, Key)} 
D: { Status(d , Closed) } 

A:{Status(d, Locked)} 

Unlock-door(R,d,k) 

P:{Type(d, Door), Nextto(R,d),Status(d, Locked), Holding(R,k),Type(k, Key)} 
D:{Status(d, Locked)} 

A:{Status(d, Closed)} 


In addition we have defined the following hierarchical operators: 


Goto-and-Pickup-key(R,k) 

Goto-objeCt(R,k), Pickup-key(R,k) 

GotO“and-Put-key-in-b6x(R,k,b) 

Goto-object(R,b), Put-key-in-box(R,k,b) 

Gotb-and-Lock-door(R,k*d) 

Goto-door(R,d), Lock-door(R,k,d) 

Goto-and-Unlock-door(R,k,d) 

Goto-door(R,d), Unlock-door(R,k,d) 

Goto-and^Close-doo^Rjd) 

Goto*door(R,d), Close-door(R,d) 

Goto-and-Open-door(R,d) 

Goto-door(R,d), Open i door(R,d). 

Pickup-and-Put-key-in-box(R,k,b) 

Goto-object(R,k), Pickup(R,k), Goto-object(R,b), Put-key-in-box(R,k,b) 
Pickup-and“Lock-door(R,k*d) 

Goto-object(R,k), Pickup(R,k), Goto-door(R,d), Lock-door(R,k,d) 
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Each of the above operators is a linear sequence of primitive operators.. The 
codesignation constraints between their, arguments is made explicit by substituting 
the same_variable name for codesignating arguments. 



Figure 8.1: Robot World Problem 

We will solve the problem in figure 8.1 The goal of the. problem, is to achieve 
Statas(D , Locked ) and In(K, B ). This problem is an example of very strong interac- 
tion. This type of interaction is more serious than the strong interaction encountered 
in Sussman’s Anomaly [Sussman, 1973]. The difference is that in Sussman’s Anomaly, 
once a plan has been developed to achieve -each-goal independently, it is possible to 
correct the plan simply by adding new actions; in this case the action of putting block 
C on the table. However, in the robot example We have presented it is not possible - 
to repair the plan in this manner, just given the two plans for achieving each goal. 


8*2.1 One Level of Abstraction 
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Figure 8.2: Plan at first level of abstraction 


We first solve the problem using only one level of predicate relaxation abstraction. 
The resulting plan at the first level of abstraction can be seen in figure 8.2. PABLO 
has. used two hierarchical-operators, Pickup-and-Put- key-in-box and Goto-and- 
Lock-door. Furthermore, it has interleaved the primitive actions, of the two op- 
erators.. This is. something most other hierarchical operator formalisms do not al- 
low. There, are two predicates in this plan, that are abstractly satisfied. They are 
StatuSjjj(door, Closed) and Inroom^j( Robot ,R2). 

In figure 8.3 We have the result of planning at the base level of abstraction. Notice 
that both abstract predicates have been satisfactorily achieved. Furthermore, the 
optimal plan is produced. It should be pointed out that problems with very strong 
interaction pose difficulties for many planners. ABSTRIPS Would not be able t.o solve 
the above problem. 
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Figure 8.3: Plan at base level 

8.2.2 Two Levels of Abstraction 

Instead of just relaxing one level of abstraction we can relax the predicates two levels. 
Doing so results in the plan seen in figure 8.4. The relaxed predicates that hold are 
Inroom^j(Robot,R2), Holdiug^fk), Status^ (door, Locked). 

Continued planning at the first, level of abstraction and at the base level results in 
the same plans asin our previous example, albeit achieved using different hierarchical 
operators. PABLO arrived at the correct plan in two different ways depending on the 
aiftount the predicates Were relaxed. 

8.3 Generalizing Predicate Relaxation 

It is also possible to generalize predicate relaxation so that predicates are regressed 
over hierarchical operators. To determine the desired regressed expression, we build 
a hypothetical abstract operator Whose add list is the union of the add lists of the 
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GoVo-6bj«t(R,B) 


P«t-k€jr-i*.box(R,K,B) 


Figure 8.4: Plan at the second abstraction level 

primitive actions of the hierarchical operator. The preconditions -of the operator 
are the bulk pfeconditions [Drummond and Currie, 1988] of the hierarchical operator. 
The bulk preconditions are those that must hold in the state where the hierarchical 
operator will be applied to guarantee that every primitive action in the operator 
is applicable. Therefore, the precondition of the hierarchical operator becomes the 
conjunction of the preconditions of the primitive actions that are not necessarily true. 
For our purposes the delete list is not important, since any expression resulting from 
the regression that contains a proposition from the delete list is subsumed by the 
proposition itself. 

Having, created this operator, .it can be used as a primitive action, for the purpose 
of regre ssing predicates through it. 

8.3.1 Shift of Semantics 

Now that we have modified predicate relaxation, it is important to discuss the im- 
plications. Before, if a relaxed predicate held at level n we were guaranteed that 
there existed a plan of ri actions or less that achieved, that predicate. Now, We are 
guaranteed that there exists a plan of « hierarchical operators or less. But this is rea- 
sonable in Light of the fact that the predicate relaxation is a measure of the difficulty 
of-planning to achieve a particular predicate. The number of hierarchical operators 
necessary to achieve a predicate is a good measure of this difficulty. 
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8.4 ABSTRIPS domain 

We will demonstrate the relaxation of predicates over hierarchical operators in the 
ABSTRIPS domain. The operators are those described in [Sacerdoti, 1974] which 
are essentially the same as those described in [Fikes and Nilsson, 1971], with the 
exception of two which are not used in the following examples. 


Gotob(R,b) 

P:{Type(b,Box),Inroom(R,rx) ,Inroom( b,rx)} 

D:{Nextto(R,$l)} 

A:{Nextto(R,b)} 

Goto(R,d) 

P:{Type(d,Door),Inroom(R,rx),Connects(d,rx,ry)} 

D:{Nextto(R,$l)} 

A:{Nextto(R,d)} 

Pushb(R,bx,by) 

P: {Type(by, Object), Pushable(bx),Nextto(R,bx),Inroom(bx,rx), 
Inroom(by,rx),Inroom(R,rx) 
D:{Nextto(R,$l),Nextto(bx,$2),Nextto($2,bx)} 
A:{Nextto(bx,by),Nextto(by,bx),Nextto(R,bx)} 

Pushd(R,dx,bx) 

P:{Type(dx,Door),Pushable(bx),Nextto(R,bx),Inroom(bx,rx), 

ConnectS(dx,rx,ry),Inroom(R,fX) 

D:{Nextto(R,$l),Nextto(bx,S2),Nextto(S2,bx)} 

A:{Nextto(bx,dx),Nextto(R,bx)} 

Gothrudr(R,d,ry) 

P-:{Type(d i Doof),Infoom(R,fx), Conn ects(d,fx,ry),Status(d, Open)} 
D:{NeXtto(R,$l),Inroom(R,rx)} 

A:{Inroom(R,ry)} 

Pushthrudr(R,bxjdx,rx) 

P:{Pushable(bx),Type(dx,DoOf)jTypc(rXiRoom),NeXtio(bx,dx), 
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Nextto(R,bx),Inr06m(bx,ry),Inroom(R,ry),Connects(dx,ry,rx),Status(dx,Open)y 

D:{Nextto(R,$l),Nextto(bx,$l),Nextto($l,bx),InroOm(R,ry),InroOm(bx,ry)} 

A:{Inroom(bx,rx),InrOom(R,rx),Nextto(R,bx)} 

Open(R,d) 

P:{Type(d,Door),Nextto(R,d),Status(d, Closed)} 

D:{Status(d, Closed)} 

A:{Status(d,Open)} 

Close(R,d) 

P:{Type(d,Door),Nextto(R,d),$tatus(d,Open)} 

D:{Status(d,Open)} 

A:{Status(d, Closed)} _ 


We have also defined the following hierarchical operators: 

Gothrudoseddr(R,dx,ry) 

Goto(R,dx), Opeit(dx), Gothrudr(R,dx,ry) 
Gotob-and-Pushb(R,bx,by) 

Goto(R,bx), Pushb(R,bx,by) 


8.4.1 Managing the Size of Relaxation Expressions 

As the number of operators grows in a domain it is important to consider Ways to 
limit the size of the relaxation expressions. There are several methods PABLO uses 
to limit these sizes. 


Removing Subsumed Disjuncts 

The relaxation definitions are .kept in disjunctive normal form. During the relaxation 
it often happens that one disjunct subsumes another one. In such situations PABLO 
remvwes the subsumed disjunct. There is no reason for retaining it, since whenever 
it holds, the disjunct which subsumes it will also hold. See chapter 6 for an example 



102 - 


CHAPTER 8. COMBINING ABSTRACTION METHODS 


where this is done for the Olear(x) predicate in the blocks world. Once hierarchical 
operators are introduced the frequency of subsumed expressions naturally rises and 
this operation can lead to substantial savings. 

Using Domain Knowledge 

Another useful method to limit the size of the relaxed expressions is to use domain 
axioms to collapse disjuncts. For example, in the Robot World domain without locked 
doors we have the axiom Status(x, Closed) => -> Status(x,Open). The result of relaxing 
the Status predicate one level is the following: 


StatusJ^x, y) 

Status(x,y) 

0 

Nextto(Robotpc) A Type(x,Door) A Status(x,Open) 

(Close(x)] 

Nextto(Robot,x) A Type(x,Door) A Status(x, Closed) 

[Open(x)] 


However, using the domain axiom, the above can be collapsed to: 


Status^jfx, y 


Status(x,y) 

Nextto(Robot,x) A Type(x,Door) 

D 

[Close(x) V Open(x)] 


This technique can lead to considerable simplification in the relaxed expressions. 


Example in the ABSTRIPS Domain 


To demonstrate how these techniques can lead to substantial savings we show the 
result of applying them to the relaxation expression of the Inr 00 m(x,y) predicate. 
Without any simplification the result of relaxing Inroom(x,y) two levels, over the 
ABSTRIPS operators, can be seen in tables 8.1 and 8.2. 

Obviously this expression is unacceptably large. However* if we make use of the 
techniques for managing the size Of relaxed expressions the resulting expression, in 
table 8.3 is considerably more compact. 
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Inrobn&i(z,y) 

Inrbom(x,y) V 

connects(z,r,y) A type(z,dbbr) A Status(z, dosed) A type(y,room) A type(f,door) A 

type(r,room) A connects(f,g,r) A Status(f,bpen) A inroom(robot,g) V 

connects(z,r,y) A type(z,door) a status(z, dosed) A type(y,room) A inroom(robot,g) A 

connects(f,g,r) A type(f,dbor) A statusff, closed) A type(r,room) V 

type(v,door) A type(y,rbom) A connects(v,w,y) A status(v,open) A type(f,door) A 

type(w,room) A conneCts(f,g,w) A status(f,open) A inroom(robot,g) V 

type(V,door) A type(y v room) A. connects(v,w,y) A inroom(robot,w) A type(v,door) A 

statusfv, dosed) A nextto(robot,v) v 

type( v ,door) A type(y^oom) A connects(v,w,y) A status(v,open) A inrocm( robot ,g) A 
connects(f,g,w) A type(f,door) a Status(f, closed) A type(w^oom) V 
pushable(x) A nextto(x,k) A nextto(fobotpc) A type(k,door) A type(y^oom) A sta- 
tus(k,open) A inroom(x,s) A eonnects(k,s,y) A type(f,door) A type(s,room) A con* 
nects(f,g,s) A status(f,open) A inroom(robot,g) V 

pushable(x) A nextto(x,k) A nextto(robotpc) A type(k,door) A type(y^oom) A in- 
room(robot,s) A inroom(x,s) a connects(k,s,y) A type(k,dbor) A status(k, dosed) A 
nextto(robot,k) V 

pushable(x) A nextto(robotpc) A type(k,door) A type(yp'oom) A btatus(k,open) A 

inrooni(robot,s) A inroom(x,s) A connects(k,s,y) A type(k,door) A pushable(x) A 

nextto(robot,x) A inroom(x,g)_A connects(k,g,h) A inroom(robot,g) V 

pushable(x) A nextto(x,k) A type(k,door) A. type(y^oom) A status(k,Open) A in-- 

room(robot,s) A inroom(x,s) A connects(k,s,y) A type(x,door) A pushable(robot) A 

nextto(robot, robot) A inroom(robot,g) A connects(x,g,h) A inroom(rbbot,g) V 

pushable(x) A nextto(robotpc) A type(k.door) A type(y,room) A status(k,open) A 

inroom(robot,s) A infoom(x,s) A connects(k,s,y) A type(k, object) A pushable(x) A 

nextto(robot,x) A inroom(x,g) A infOoni(k^) A inrooin(fobot,g'/ V 

pushable(x) A nextto(robotpc) A type(k,door) A type(y t room) A status(k,open) A 

inroom(robot,s) A inroom(x,s) A connects(k,Sjy) A type(x,objett) A pushable(k) A 

nextto(robot,k) A inroom(k,g) A intobm(x,g) A inroom(robot,g) V 

pushable(x) A nexttc(x,k) A type(k,door) A type(y,rooin) A status(k,open) A in-. 

foom(fobot,s) A inrbbm(x,s) A connects(k,s,y) A type(x, object) A pushable(robot) A 

neXttofrdbot, robot) A inroom(robot,g) A inrdom(x,g) A inroora(robot,g) V 


Table 8.1: First half of relaxation expression. 
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pushable(X) A neXtto(x,k) A type(k,door) A type(y v room) A statuS(k,open) A in* 
rodm(robot,s) A inroom(x,s) A connects(k,s,y) A type(robot, object) A pushable(x) A 
nextto(robotpc) A inroOm(X,g) A inroom( robot ,g) A inroom (robot ,g) V 
pusfcable(x) A nextto(robotpc) A type(k,door) A type(y,room) A status(k,open) A in*-. 
roo?n(robot,s) A. inroom(x,s) A connects(k,s,y) A type(k,box) A inroom(k,g) A in- 
room(robot,g) V . 

pushable(x) A nexttO(x,k) A type(k,door) A type(y,room) A $tatus(k,opeii) A in- . 
room(robot,s) A inroom(x,s) A connect$(k,s,y) A type(x,box) A inroom(x,g) A in- 
room (robot ,g) V 

pusbable(x) A nextto(robotpc) A type(k,door) A type(yproom) A status(k,open) A in- 
rootnl robot ,s) A inroom(x,s) A connects(k,s,y) A type(k,door) A connects(k,g,h) A in- 
room(robot,g) V 

pusbable(x) A nextto(x,k) A type(k,door) A type(y v room) A status(k,open) A in- 
room(robot,s) A inr00m(x,s) A cpnnects(k,s,y) A type(x,door) /\ connects(x,g,h) A in- 
room(robot,g) v 

pushable(x) A nextto(robot r x) A type(k,door) A type(y^oom) A status(k,open) A in- 
room(robot,s) A intoom(x,s) A connects(k,s,y) A inroom(robot^) A inroom(x,g) A 
type(x,bOx) A inroom(k,h) A pushable(x) A type(k, object) V 

pushable(x) A nextto(robotpc) A type(k,door) A type(yp-oom) A Status(k,open) A in- 
room(robot,s) A inroom(x,s) A c6nnects(k,s,y) A inroom(robot^) A inroom(k,g) A 
type(k,box) A inroom(x,h) A pushable(k) A ;ype(x, object) V 

pushabie(x) A nextto(x,k) A type(k,door) A. typt^yjoom) A statu$(k,open) A in- 
foom(:robot,s) A inroom(x,s) A connects(k,s,y) A inroom(robot,g) A type( robot, box) A 
inroom(xdi) A pushable(robot) A type(x, object) V 

pushable(x) A nextto(x,k) A type(k,door) A type(y^oom) A status(k,open) A in- 
room(robot,s) A inroom(x,s) A connects(k,s,y) A inroom (robots) A inroom(x,g)_A 
type(x,box) A pushable(x) A type(robot, object) V 

pushable(x) A nextto(x,k) A nextto(robotpc) A type(k.door) A type(y^oom) A sta- 
tus^, open) A inroom(x,s) A connect$(k,s,y) A inroom(robot,g) A connects(f,g,s) A 
type(f,door) A status(f, closed) A type(s,ioom) V 

pushable(x) A nextto(x,k) A nextt6(robot,x) A type(k,door) A type(y,room) A sta- 
tus(k,open) A inroom(robot,s) A infOOffi(x,s) A cofinects(k,s,y) V 
type(v,door) A type(y,room) A connetts(v,W,y) A status(v,open) A inr l oom(robot,w) V 
inroom(robotj) A connects(z,r,y) A type(z,dOQr) A statuS(z, closed) A type(y,room) 


Table 8.2: Second half of relaxation expression. 
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Inroom^i(j,y) ^ 

connects(z,r,y) A type(z,door) A type (y, room) A inro0m( robots) A connects(f,g,r) A 
type(f,door) a type(r,rOdm) V 

pushable(x) A. nextto(x,k) A nextto(robdt,x) A type(k,door) A type(y,rdom) A in- 

rodm(robdt,s) A inroom(x,s) A-Connects(k,s,y) A nexttd(rdbdt,k) V 

pusbable(x) A nexttd(x,k) A type(k,door) A type(y,room) A status(k,dpen) A in- 

r6om(robot,s) A >nroom(x,s) A connects(k,s,y) A type(X,box) V 

inroom(rdbot,r) A connects(z,r,y) A type(z,dodr) A type(y,ro6m) V 

pushable(x) A nexttd(x,k) A next to( robots) A type(k,dddr) A type(y r rddm ) A sta- 

tus(k,dpen) A inrddm(rdbdt,s) A inr^o.n(x,s) A Cdnnects(k,s,y) 


Table $.3: Relaxed expression using the simplification filters. 
While simplifying the expression we made use of the domain constraint 


Status(x, closed) => ->Status(x,open) 

Notice that by using this constraint. PABLO can capture the notion that it does 
not matter whether a door is open or closed, since PABLO has operators for either 
case (Gothrudr and Gothrucloseddr). All that is important is that there is a door 
between two rooms. 

We can See that with a few simple techUiques it is possible to achieve a sizable 
reduction in the size of the relaxed expressions. If the expression becomes unman* 
ageably . large even using these simplification techniques, PABLO stops relaxing the 
predicate. The user can set a threshold for. the maximum allowable size for. each 
relaxation predicate. This might result in PABLO performing additional planning 
at a higher level than it otherwise would, but this might be preferable to having an 
enormous and unwieldy relaxation expression to evaluate. 


8.4.2 Example from ABSTRIPS 

We gave PABLO the problem presented in [Sacerdoti, 1974] for purposes of compar- 
ison. The problem can be seen in figure 8.5. In this figure (a) represents the initial 
state and (b) is the goal state. 
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Figure 8.5: Problem that ABSTRIPS solves 

PABLO begins planning at abstraction level 3. The plans generated after each 
abstraction level can be seen in figure 8.6. ABSTRIPS also uses four levels of ab- 
stractions for this problem. 

The plans generated at each abstraction level by PABLO and ABSTRIPS are 
remarkably similar. . This is probably due mostly to the nature of the problem and 
domain. ABSTRIPS is a linear planner . and this is a linear problem, without strongly 
interacting subgoals. It is not surprising that both planners would generate similar 
plans at different levels of abstraction. 

GivenJudifferent problem in a similar domain, such as the previous problem with 
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GotobfR, Bagel) 


P»thb(R,BogU,Bax2) 


Uv«I S 


GofcSb(R,Baxl) 


“| Puibb(R,Baxl,Bagc2) 


Uvtl 2 


G<Hhrudi(R,D»b,A) 


Gothrudr(R,Dfe,E) Cotab(R.BcgU) 
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Gotbradr(R,D»b,A) 


Uvtl 1 



But Uvtl 


Figure 8.6: PABLO’s solution 


very strongly interacting goals the similarity obviously ends, since ABSTRIPS is 
unable to solve the problem.. Also, given a different domain, such as the Towers of 
Hanoi, the two-planners’ behaviour might differ considerably. In the Towers of Hanoi 
domain, ABSTRIPS can use only one level of abstraction, mo matter the complexity 
of the problem given, whereas PABLO generates . n — 1 levels of abstraction for n 
disks. 
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8.5 Summary 

We have presented two examples where state and operator abstraction are combined 
to produce interesting planning behaviour. We have extended predicate relaxation to 
include the relaxation of predicates over hierarchical operators. Finally, we demon- 
strated techniques whereby the size of predicate relaxation expressions can be sub- 
stantially reduced. 



Chapter 9 

Classical Truth Criterion 


9.1 Introduction 

A truth criterion defines the conditions under which a predicate is true in a particular 
situation of a plan. Such a criterion is important since a planner must often check 
the truth of propositions during planning, e.g. to determine if a proposition of a 
precondition is satisfied. Because the underlying plan representation varies from 
planner to planner the truth criteria of planners. have varied as well. 

As we shall see, in some special plans, namely those where the actions are lin- 
early ordered and where every predicate is ground, defining a truth criterion is rela- 
tively straightforward. Once we introduce variables, nonlinearity, conditional actions, 
deductive rules, typed variables, etc., defining a truth criterion becomes more com- 
plicated. .For example, once we introduce nonlinearity, the truth of a predicate at 
a certain point in the plan depends on -the possible orders of the actions preceding 
the point of interest. In this case we no longer speak simply about the truth of a 
proposition, but about the possible or necessary truth-of a proposition. 

The first formal definition of a truth criterion for partially ordered plans can. 
be found in [Chapman, 1987]. Chapman refers to this criterion as the Modal Truth 
Criterion. The Modal Truth Criterion was defined for a particular plan formalism: 
Chapman’s TWEAK formalism. As Chapman points out, TWEAK is a very re- 
stricted planning formalism. Further, even minor extensions to the formalism results 
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in the truth criterion no longer being valid. 

In this chapter, we discuss the previous work by Chapman, and then present a. 
new planning ontology that is powerful enough to capture most planning formalisms 
proposed up. until now. .We then present, a new Classical Truth Criterion for this 
planning formalism. This truth .criterion is proved, sound and complete. 1 Finally, 
we discuss some of the implications of the Classical Truth Criterion, and present an 
algorithm for checking the truth of a predicate in a plan. 


9.2 Modal Truth Criterion 

Chapman introduces the following truth criterion: 

Definition 6 (Modal Truth Criterion) A proposition p is necessarily true in a 
situation s iff two conditions hold: there is a situation t equal or necessarily previous 
to s in which p is necessarily asserted; and for every step C possibly before s and 
every proposition q possibly codesignating with p which C denies, there is a step W 
necessarily between C and s which asserts r, a proposition such that r and p codesignate 
whenever p and q codesignate. The criterion for possible truth is exactly analog ous, 
with all the modalities switched (read “necessary” for “possible” and vice versa). 

In Chapman’s logical notation, the criterion reads as follows: 

3t ;< s A □asserfedm(p,<)A 
VC □ s * CV 

Vg □ -'denies (C,$)V 
□9 9 & pV 

3WaC<WA 

aw •< sa 

3 r asserts( W, f)Ap«$=>p«r 

‘A truth criterion is sound if whenever it holds for a predicate p and a situation b the predicate 
p is true in situation s. A truth criterion is complete if whenever p is true in situation S the truth 
criterion holds for predicate p in situation s. 
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There is a typo in Chapman’s logical formulation of the Modal Truth Criterion. 
In order to make the formula conform to the English version we need to replace 
3r ass6rts(w , r)Apftsq=^pfar. 
with _ 

3r a$serts(w,r) A D(p « q =3- p « r). 

In what follows we will refer to this criterion as MTC. The MTC is proven by 
Chapman to be valid for plans represented in TWEAK’S formalism. For a-complete 
description oLTWEAK see [Chapman, 1987]. An action in TWEAK has a precondi- 
tion and a postcondition, each of which are sets of predicates which must hold before 
the application of the action and after the application of the action respectively. 
Plans in TWEAK are partial orders of actions. The TWEAK formalism explicitly 
excludes restricting variables to a finite domain, conditional actions, and deductive 
rules. Chapman notes that if TWEAK is extended in any of these ways the Modal 
Truth Criterion fails. For example, in order to guarantee, 

->MTC ^ ->OHolds(p,s) . 
or 

Vf Os -< t V 0->asserts(p, t)V 
3c O c ;< sA 

3q Odenies(c t q)A 
O q tt pA 
Vie Ow ^ cV 
Os •< toV 

Vr ->asserts(w> r ) V 0(p ta q A p r) 

-<£1 Holds(p,$) 

it-must be the case that if no action necessarily asserts p then p cannot necessarily 
hold. Although this is the case for the plan representation used in TWEAK it is not 
the case for many representations which are just somewhat more-expressive. For 
example, if we allow restricted ranges on variables we can have situations where no 
Step necessr rily asserts a proposition but Where the proposition is asserted by some 
step in all ground linear completions of the plan. Take the plan in figure 9.1. 
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x - <A,B> y «* {A,B> x * y 


Figure 9.1: Restricted Range Plan. 

In this plan Clear(A) holds in situation s, however the Modal Truth Criterion fails 
to determine this. 

Restricting the range of variables can greatly reduce the planning time in certain 
cases. SIPE is the main planner which makes use of this feature for great compu- 
tational savings. A-truth criterion that can deal with this extension is therefore an 
important contribution. 

We have a similar problem if we extend our plan representation to allow arbitrary 
deduction performed in situations. We have to be careful when extending our lan- 
guage to handle this. Lifschitz [Lifschitz, 1986] has shown that fOr a planner which 
uses STRIPS style operators to remain sound it is necessary that any axioms we use 
must hold in all states of the domain. However, if we allow such axioms in our plan 
language the completeness proof of the Modal Truth Criterion fails since We can now 
have two actions which synergistically assert a proposition in a way similar to that of 
figure 9.1. 




9.2. MODAL TRUTH CRITERION 


113 


For example, suppose we are in a blocks world which allows more than One block 
on another. We might want to include a deductive rule which determines that if no 
block is on top of a -particular block then that block is clear. This rule would usually 
be applied after a block has been moved from one location to another. This is not— 
equivalent to simply adding Clear(x) to the postcondition of the mOveJblock(y,x,z) 
operator, since not all block moves result in x becoming clear. 



L3 

L 

_1L 



c 




Figure 9.2: Deductive Plan 

Take example 9.2. In this example each move operator has On(x^y) in the delete 
list, where x 4s the block being moved. However, it does -not have Clear(y) in the add 
list, since it might be the case that there are-remaining blocks on y. To determine if a 
block y is clear the planner must use the following axiom (-’3z On(x, y)) =>• Clear.(y). 

In our example, it is the case that clear(C) holds in state S. The Modal Truth Cri- 
terion would not recognize this since no action prior to s necessarily asserts clear(C). 

Ifl what follows we present a planning formalism which generalizes most of the 
powerful plan representations proposed in the literature to date. We then present a 
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Classical Truth Criterion which is proven valid for this formalism, and as a conse- 
quence, the formalisms which it subsumes. 

9.3 The Classical Planning Ontology 

In this section we present our ontology, upon which we will base our logic, and present 
the truth criterion. 

A plan Consists of the following components: 

A ,a n }, a set of n actions. 

P A possibly infinite set of predicates. 

W_< A partial order A x A. 

W^asserts A binary relation Ax P. 

W.dfinies A binary relation Ax P. 

WJnitially A unary relation on P. 

W_ground- A unary relat ion on P. 

WJiolds A binary relation P x A. 

Notice that we have said nothing about the structure of actions or predicates for 
that matter, only that they exist. It is important to make the distinction at this point 
between the predicates in P, which are predicates on the particular domain the-planner 
is Operating in, e.g. ON(x,y), CLEAR(x) in the blocks world, and the predicates in the 
logical language used to describe the truth criterion, e.g. asserts(W,r) in Chapman’s 
logic. 

A ffiddel is a Kripke structure such that: 

* The worlds are plans. 

• A, P, WJnitialiy, and W .ground do not vary from World to world. 
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We define some worlds as being GLP (ground-linear plans): 

Definition 7 (GLP) GLP(xjb) iff in world w, W_< defines a total order on A and for 
every predicate p such that there is some action a and some pair (a,p) € (W_asserts 
U W -denies ) it is the case that p €_W-ground. 

Further, the worlds in our Kripke st ructure are related by the following two rela- 
tions: 

Definition 8 (S) <£(^1,102) is any reflexive, transitive relation such that whenever 
GLP(w i) then S( viuWi) = (u>i = ^2)- 

Definition 9 (C) C(wi,w 2 ) iff S(wi,w 2 ) and GLP(w 2 ). 

This completes our ontology. Notice that the relation S is not completely specified. 
The point is that any relation with the necessary properties we have defined will 
be adequate for our purposes. The relation S will vary from planner to planner, 
depending on the planner’s particular method of specializing plans. 

Further notice that this ontology can. be used to represent planning formalisms as 
diverse as STRIPS, TWEAK, SIPE, NOAH, NONLIN, etc. This is because we impose 
no constraints on the structure of actions, and allow the. relations W-<, W .asserts, 
Wjdenies, to vary from world to world, thus allowing for nonlinearity, conditional 
actions, deductive rules, etc 


9.4 Classical Plan Logic - 


In order to reason with our ontology we need a language which will allow us to make 
precise statements about our model. Not surprisingly, we will use a first-order modal 
logic. We define symbols for the members of A and P. For simplicity of exposition We 
Will use the same symbol names in oUr logic as in~the model; if a 6 A in the model 
then a is an action ir our logic. We then define the folloWingjtglatiOns: 

■K (Ui 62) iff (01,02) € W_<. 
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asserts asserts(n,p) iff ( a,p ) € W .asserts. 

denies denies(n,p) iff (a,p) € W .denies. 

initially initially(p) iff p € Winitially. 
ground ground(p) iff p € W_ground. 
holds holds(p,a) iff (p,o) € W_holds. 

We intend holds(p,n) to be true if predicate p is true just before action a is 
executed; initially (p) is true if p is true in the initial Situation; asserts(n,p) is true 
if action a asserts -predicate p; denies(c,p) is true if action a denies predicate p; 
ground(p) is true if predicate p contains no variables in its argument list; a.\ -< a 2 is 
true if action dj must be executed before action a 2 . 

We also have two sets of modal operators: □$, Os defined in the usual manner on. 

the accessibility relation S, and □,<> defined on the accessibility relation C. 

We will need the following properties of our logic: 

□(i 5 A Q) = UP A UQ 
O(PVQ) =OPvOQ. 

OP A OQ =£• 0(P A Q) 

O s (P A Q) = □ S P A □ S Q 
O S(P V Q) = 0-$P V OsQ 

These are true in all standard models of modal logic and therefore also in ours. 

VxOP => □VziL(Butcan Formula) 

3xO.P =► DBiP 

WxO s P =£• Q 5 V 2 P (Bax can-Formula) 

BiDsjP => Os3i\P 

This follows from the fact that we are using a fixed domain, i.e. the objects in 
out domain (actions and predicates) do not vary from World to World. We can prove 
the Barcan formula as follows. If, in a plan a t yxOP then it is the case that □ P is 
true in a no matter what value x takes. But then for all plans (3 such that a C/3 it 
is the case that P is true no matter what Value x takes. But this means that VxP 
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is true in plan 0. Which in turn means that ClVarP is true in plan a. 2 The proof 
for 3 xOP =$> D3xP is similarly straightforward, and the proofs for □$ and O 5 are 
analogous. . 

O s OP OP 

If ha OsOP then there exists some plan a' and some plan 0 such that aSa'. and 
ol'C0 and f=p P . 3 We -just need to show that aC0. But this is clearly true, since 
a'C@ implies <x.'S0, which by transitivity implies aS0. Furthermore, GLP{0) which 
implies aC0. 

□sPL=» DP 

This follows directly from the definitions of C and S. Specifically, for all plans a 
and 0 whever aC0 it is the case that aS0. Therefore, if f= w P for every u> such that 
aSu>, it must be the case that |=( P for every £ such that aC (. 

0(0 P = P) 

□(□P = P) 

These two axioms follow from the fact_that the only ground linear completion of a 
ground linear completion a is a. Therefore f=: a OP is equivalent to (= Q P and DP 
is equivalent to f = 0 P. 

9,4.1 STRIPS Assumption 

We are almost done with the definition .of our logic. It turns out that to prove our 
Classical Truth Criterion we need one axiom: 

□(Holds(p,a) = 

(^36(6 -< a) A initially(p)) V l 

3c((c -c a) A -*3d((c -< d) A (d -< a))/\ v 

(asserts(c,p) V (ttolds(p, c) A ->denies(c,p))))) 

Interestingly enough, if we take the STRIPS assumption to be: 


3 For a discussion of the Barcan formula see [Hughes and Cresswell, 1988] pp. 147-148. 
3 The notation [=„ P means that |= P in plan (world) 0 . 
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The truth value of a predicate does not change unless it is explicitly 
asserted or denied by an action in the plan. 

Then it should be clear that our axiom is merely a restatement of this principle.in 
our logic. Therefore, we will refer to this axiom as the STRIPS Assumption Axiom. 

9.4.2 Lemmas 

In our proof of. the Classical truth Criterion we will need the following lemmas which 
follow directly from the STRIPS Assumption Axiom. 

Lemma 9.4.1 


□(( ->5 6 (6 -< a) A ->Initially(p)) =*> ->Holds(p, a)) 


Lemma 9.4.2 

□((36 (6 -< a) A -’3c ((6 -< c) A (c -< a)) A -’Holds(p, 6) 
A-<asserts(6,p)) ^ ->Holds(p, a)) 


Lemma 9.4.3 

□((36(6 ^ a) A -’3c((6 -< c) A (c -< a)) A denies(6,p) A -iasserts(6,p)) 

i ’Holds(p, c l) 


Lemma 9.4.4 


□(Initially (p) =» (Holds(p,a) V 36(6 -< a))) 


Lemma 9.4.5 


□(36(6 -< a) A ->3c((6 -< c) A (c -< a)) A 
(->3836^8(6^) => Holds(p,6) A->denies(6,p)) 
=► Holds(p,a)) 
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9.4.3 —First attempt at defining a new truth criterion 

One obvious truth criterion is the following formula: 

nHolds(p,a) = 

□((—36(6 -< a) A initially (p))V 
3c((c -< a) A -n3d((c X d) A (d -<.a))A ' 

(asserts(c,p) V (Holds(p,c) A -’denies (c,p))))) 

This follows directly from the STRIPS Assumption Axiom. It should be obvious 
that this definition is not particularly useful since it requires us to examine every 
ground linear completion of a plan to determine the truth of a proposition in a 
situation. 

We now present a new truth criterion which is powerful enough to correctly handle 
an extended plan representation, yet allows, us to determine the truth of a proposition 
more efficiently th an simp ly examining every ground linear completion of the current 
plan. 


9.5 Classical Truth Criterion 

In our language the Classical Truth Criterion is expressed as follows; 
□ Holds(p,a) = 

□5 (((—>36 0(6 X a)) =► QInitially(p))A 

Vc (n(c -< a) A ~>3 d 0((c -< d) A (d -< a))) => 

(- 1 O asserts (c,p) =*• 

□Holds(p,c) A -«Odenies(c,p))) 


Proof: . 

We will refer to the right hand side of the equivalence as TC. First we prove that 
if p holds before an action a of all ground-linear completions of a plan then the truth 
criterion m. .at hold for that plan. .This is done by proving the contrapositive, namely 
that ->7 , C(p j a) => -•□Holds(p j a). 
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<>$((->36 0(6 -< a) A -’□Initially(p)) 

V3c (0(6 -< a) A 0((c -< d) A (d -< a)) 
A->Oasserts (c, p) A „ 

(-.□Holds(p, c) V Odenies (c,p)))) 

==> -’□Holds(p,a) 

Using O s{P V Q) = OsP V OcQ we can rewrite the above. 

0^((— ’36 0(6 -< a) A ^0 Initially (p))) 
V 05 ( 3 c (D(c -< a) A ->3 d 0((c -< d) A (d -C a)) 
A^Oasserts(c,p)A 
( -i □ Holds (p,c) V Odenies(c,p)))) 

=£• -’□Holds(p,<z) 

Using^ P V Q =>• P = (P P) A (Q => P): 

Os(( -, 36 0(6 -< a) A -'□Initially(p))) 

^ -’□Holds(p,a) 

A 

Os(3c (D(c -< o) A ->3 d O((o X d) A (d -< <z)) 
A->Oasserts(c,p)A 
(-'□Holds(p, c) V Odenies (c, p )))) 

=*• ■ i ’DHolds(p, a) 


(9.3) 


(9.4) 


(9.5) 


We first show: 


Os((-»36 0(6 -< a) A -’Olnitialiy(p))) 

=?> -’□Holds(p,a) 

Since -’360(6 -< a) = □->36(6 -< a) we can rewrite the antecedent: 


(9.6) 


( 9 , 7 ) 


Os(D->36 (6 -< a) A -’□Initially(p)) 
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Now, since ->nP = <C >->P: 


(b -< a) A O-'Initially(p)) 

Because CP A OQ => O (P A Q): 


O^C(->36 (6 -< a) A -'lnitially(p)) 


Since Os OP *=► OP: 


0( ‘‘Bi (6 -< a) A Initially (p)) 


L ;r .;u* ...4.1: 


0-Kolds(p,a) 

Which is equivalent, to -'□Ho!ds(p, a) which is what we wanted to show. 
We still need *t- ;hcw par' (2) cf equation 9.5. 


OsjBc 1 0(c -< a) A ->3d O((o ~< d) A (d •< a)) 
A-«Oasserts(c, p) a 
(->DHolde(p, c) V-Odeniesfc,p)))) 
“iOHolds(p,a) 


We distribute over V. 

Os(3c (D(c •< a) A ->3d 0((c -< d) A (d -< a)) 
A-'Oasserts (c, p) A 
-’□Holdup, c))V 

(□(c -< a) A -0d 0((c -< d) A (d ■< a)) 
A->Oasserts(c,p)A 
Odenies(c,p))) 

=$t_=iOHolds(p, a) 


(9.8) 

(9.9) 

(9.10) 

(9.11) 

(9.12) 

(9.13) 
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We distribute 3c over V. — — 

<^s(3c (D(c -< a) A -«3d <>((c -< d) A (d -< a)) 
A - -'OaSserts(c, p) A 
-'□Holds(p,c))V 

3c(D(c -< a) A -»3 d 0((C -< d) A (d ■< a)) 
A-’Oasserts(c, p) A 
Odenies(e,p))) 

=*■ “'□Holds(p,a) 


Using Os(P V Q) = O sP V O s Q 

05(3c (D(c -< a) A -<3d 0((c -< d) A (d ■< a)) 
A-’Oasse:ts(c,p)A 
->DHolds(p,c)))V 

Os(3c(0(c -< a) A -'3d 0((c -< d) A (d -< a)) . 
A->Oasserts(c, p)A 
Odenies(c,p))) 

-'□Holds(p,a) 

Using P V Q R s (P =» R) A (Q R): 

Os(3c (D(c ■< a) A ->3 d 0((c -<.d) A (d -< a)) 
A->OaSserts(e,p)A 
-•□Holds(p v c))} =4» -’□Holds(p,fl) 

V 

Os(3c(D(c -< a) A “'3d 0((c -< d) A (d -< a)J 
A-»OaS$erts(c, p) A 
Odenies(c,p))) 

->OHolds(p, g) 


(9.14) 


(9.15) 


(9.16) 


We now show: 
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O s (3c (C3(c -< a) A ~>3d 0((c -< d) A (d -< a)) 
A^>Oasserts(c,p)A 
-»QHolds(p, c))) => -'□Holds(p,a) 

3 xO P =$> 03 xP and ->OP = □~>P. 

Os(3c (□(<: -< a) A 0->3d ((c -< d) A (d -< a)) 
AO-iasserts(c,p)A 
0-iHolds(p, c))) 

DP A OQ =* 0(P A Q) 

Os(3c 0((c -< a) A ->3d ((c ■< d) A(d ~< a)) 
A->asserts(c, p)A 
-iHolds(p, c))) 

3e OP(c) 03c P(c): 

OsO(3c (c -< a) A i3d ((c ~<d) A (d -< a)) 
A->assertS(c, p) A 
~'Holds(p, e)) 

O s OP =*> OP: 


0(3c (c -< a) A ->3 d ((c -< d) A (d ■< a)) 
A-»asserts(c,p)A. 

-'ttolds(p, c)) 

Applying Lemma 9^4.2: 


0-iHolds(p,a) 

Which is equivalent to -'□Holds(p, a). 

We still need to show: 


(9.17) 


(9.18) 


(9.19) 


(9.20) 


(9.21) 


(9.22). 
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Os(3o(d(e -< a) A ->3dJ>((c -<d) A (d -< a)) 

A-'C , asSerts(c,p)A 

Odeiiies(c,p)_)J (9.23) 

~>DHolds(p,a) 

-’OP =>■ D-i P. 

0$(3c(D(c -< a) A □— «3cf ((c -< d) A (d -< a)) 

AC3-’asserts(c,p)A (9.24) 

Odenies(c,p))) 

OPAOQ^O(PAQ): 

<0>s(3cO((c -< a) A ->3d ((c -< d) A (d -< c)) 

A-’asserts(c,p)A (9.25) 

denies(c,p))) 

3aOP(o) =► 03aP(a) 

0$0(3c(c -< a) A -’3d ((c -< d) A (d -< a)) 

A->asserts(c,p)A (9.26) 

denies (c, p)) 

O s OP =» OP 

0(3c(c -< a) A -’3d ((e ^ d) A. (d -< a)) 

A-’asserts(c,p)A (9.27) 

denies(c,p)) 

Using Lemma 9.4.3: 

0-’Holds(p,a) (9.28) 

V hich is equivalent to -’□Holds(p,<2)._We are now done proving □Holds(p, a) =$■ 
TC. We now show TC ^ □Holds(p,a). 
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□5 (((—‘36 0(6 -< a)) □Initijilly(p))A 

Vc (D(c -< a) A ->3d 0((e -< d) A (d -< a))) =► 
(->0 asserts (c,p) => 

□Holds(p,jc) A ->0denies(c, p))) 


0 S (P A Q) => n 5 P A n 5 g: 

□5 ((->36.0(6 -< a)) =*■ □Initially(p))A 

□s(Vc (□(<:_-< a) A -’3 d 0((c -< d) A(d -< a))) =► 
(-> O asserts(c,p) ^ 

□Holds(p,c) A ->Odenies(c,p))) 


We begin by showing: 

Os((-i36 0(6 -< a)) =>• □Initially(p)). 
=> 0(Holds(p, 6) V 36(6 -< a)) 
360(6 ■< a) =► 036(6 -< a): 

□5((->036 (6 -< fi)) □Initially(p)) 

->OP =$> O-P. 


D S P =}► DP; 


□5((d-«36 (6 -< a)) =» □Initially(p)) 


□(□P s P): 


□((□-<36 (6 -< a)) =► □Initially(p)) 


□((->36 (6 -< a)) =► Initially(p)) 


(9.29) 

(9.30) 

(9.31) 

(9.32) 

(9.33) 


Rewriting, 
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□((36 (6 X a)) V Initially(p)) 

Using lemma 9.4.4: 


□(Initially (p) =*• (36(6 •< a)) V Holds(p, a)) 

Therefore: 


□((36 (6 ■< a)) V Holds(p, d)) 

We now show: 


□s(V , c(D(c -< a) A — '3<i 0((c -< d) A (d -< a))) ^ 
(-iOasserts(c,p) =$► (.□Holds(p,c) A -<Odenies( c,p)))) 
=$■ □(Holds(p, a) V -i3e(e -•< a)) 

-*CP = C-P and BiOP =£• 03xP. 


□ 5 (Vc(D(e “n a) A □->2d ((c -< d) A (d -< a))) =» 
(□"iasserts(c,p) =» (□Kolds(p, c) A □->denies(c,p)))) 

□si 5 =» DP: 


□(Vc(D(e -< a) A D-.3d ((c -< d) A (d < a))) => 
(□->asserts(e,p) =» (□Holds(p, c) A □->denies(c,p)))) 

□(□p =.py 


□(Ve((c -< a) A ->3 d ((c -< d) A (d -< a))) =>• 
(-’asserts(o,p) =» (Holds(p,c) A -’denies(c,p)))) 

(3e(e •< a) V -»3e(e -< a)) A P => (3e(e -< d) A P)V ->3e(e -< a) u . 

□((3e(e -< a) A Vc((c -< a) A ->3d ((c -< d) A (d -< a))) =► 
( -^asserts( c.p) => (Holds(p,c) A ->deiiies(c,p)))) 
V(-'3e(e d))) 

Since a ground linear plan is a total order the following holds: 


(9.34) 

(9.35) 

(9.36) 

(9.37) 

(9.38) 

(9.39) 

(9.40) 

(9.41) 
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□(36(6 = 3 /(/ xa)A i3 g(f -<g) A (^ a)) 

Therefore^ 


Q((3/(/ -< a) A ->30((/ -< g) A (p -< d)) A Vc((c -< c) A ->3d ((c -< d) A (d -< a))) =>• 
(~iasserts(c,p) =$► ( Holds (p,_c) A -’denies(c,p)))) 

V(->3e(e -< a))) _ 

(9.42) 


We use universal instantiation and simplify: 


D ((3/(/ -< a) A -'3g((f -< g). A {g < a)) A 
(-’asserts(/,p) (Holds(p,/) A ->denies(/,p)))) 
V(-i3e(e -< a))) 

Using lemma 9.4.5: 


(9.43) 


□(Holds(p,a) V (-»3e(e -< d))) (9.44) 

Therefore: 

□(Holds(p, d) V 36(6 -< d)) A □(Holds(p, a) V -de(e -< a)) (9.45) 

QP A aQ =► D(PA(5): 

□((Holds(p, a) V 36(6 -< d)) A (Holds(pjd) V -?3e(e -< a))) (9.46) 

Rewriting: 

□(Holds(p, d) V (36(6_.*< a) A -'3e(e -< d))) (9-47) 

Which is equivalent to: 

□Holds(p,a) (9.48) 

□ Q.E.D. 

This completes our proof of the Classical Truth Criterion. 
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9.6 Algorithm for checking truth criterion 

We can make use of two properties of the truth criterion to increase the efficiency of 
a truth checking algorithm. The.first is that if. the truth criterion is non-trivially true 
in a plan, then it is true for all specialisations of it. 

By non-trivially true we mean that either a is the first action of the plan and 
□ Initially (p), or there is some action c immediately before a and 

-'Oasserts(c, p) A □Holds(p,c) A -lOdeniesfcjp). 

It is important to note that if there is some action c immediately before a there 
can be. no other action immediately before a. This property guarantees that both 
conditions imply the Classical Truth Criterion. 

We show, 


(((->36 0(6 -< a)) A Dlnitially(p))V 
3c(D(c -< a) A -’3d 0((c -< d) A (d -< a)))A 
(-’OaSserts(c, p) A □Holds(p,c) A ->Odenie$(c,p))) 

=* (9.49) 

d s.((( _, 36 0(6 -< a.)) A □Initially(p))V 
3c(D(c -< a) A -’3d 0((c -< d) A (d -< a)))A 
(-’Oas§erts(c,p) A □Holds(p,c) A ->Odenies(c,p))) 

Proof: 

Rewrite~the antecedent: 

(((V6 □-’(6 -< a)) A □Initially(p))V 
3c(C(c -< a) A Vd □->((c -< d) A (d -< a ))) A (9.50) 

(□-iasserts(c,p) A □Holds(p,c) A D-’denieS(c,p))) 

Use DP □ 


(((V6 □5D-i( 6 -< a)) A □sDlnitially(p))V 
3 c(O s D(c -< a) A Vd □ s D-‘((c -< d) A (d -< a)))A 
(□5D-’assefts(c,p) A □sDHolds(p,c) A □50-’denies(c,p))) 


(9.51) 
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Use the Barcan formula: 

(((□ 5 V6 0^(6 ■< a)) A □$dInitially(p))V 
ae(d 5 C3( c ~< a) A n s Wd^((c -< d) A {d -< a))) A (9.52) 

(□ s D-iasserts(e,p) A □ 5 dHolds(p,e) A □sC3r>denies(c,p))) 

Use 0$P A OsQ => ds^i 3 A Q ) j 

□ S ((V6 □~>(6 «' a)) A dInitially(p))V 
3cO$(n(c -< a) A VdD-'((c -< d) A (d -< a)))A 
(□->asserts(c, p) A OHolds(p,c) A □->denies(e,p))) 

Use the Barcan formula: 

□$((V6 □-'(6 -< a)) A □Initially(p))V 
□s3c(D(c •< a) A Vdd-i((e -< d) A (d X a)))A 
(□-iasserts(c,p) A □Holds(p,c) A □->denies(c,p))) 
d 5 P V D s Q =» d s (P V Q) 

d$(((V6 d-*(6 -< a)) A □Initially(p))V 
3c(d(c -< a) A V<fd->((c -< d) A (d c)))A 
(Q=3asSerts(c < p) A □Holds(p,c) A □*-'denies(c,p))) 

Rewrite: 

d 5(((“’36-0(5 -< a)) A □Initially(p))V 
3c(d(c ■< a) A ->3dO((c -< d) A (d a)))A_ 

(-’Oasserts(c, p) A □ttolds(p,c) A -'Odenies(e,p))) 

Q.E.D. 

The other is that only plans in which the following holds can possibly fail the 
truth criterion: 

-■'3 b 0(6 -< <t)V 

3cd(c -< a) A -'3 d 0((c -< d) A (d -< 0 )) A -’Oasserts(c,p) 

Ati algorithm for checking the truth criterion then only has to examine the “weak- 
est” specializations such that, the above condition holds to see if Oholds(p, c) A 


(9.53) 


(9.54) 


(9.55) 


(9.56) 
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Holds(p,a) 

For every distinct, minimal specialization such that there is an action c 
immediately before a and C does not possibly assert p 

check that c does not possibly deny p and necessarily Holds(p.c). 

If theteis a minimal specialization such that a is the first action 
check that initially(p) necessarily holds. 

Table 9.1: Algorithm for checking truth criterion. 

-’Odenies(c,p). The details of the algorithm will vary from planner to planner de- 
pending on their underlying plan representation, however a high-level description of 
it can be found in table 9.1. A specialization u>i satisfying A condition is minimal if 
there is no other specialization satisfying that condition Such that S{w$,w\). 

This algorithm does not necessarily require that every ground linear completion 
of the plan be checked. Suppose we are given the -plain in figure 9.3. In this exam- 
ple we assume the TWEAK planning formalism, extended with restricted ranges on 
variables. We are interested in knowing whether the precondition, P(A,B) of action 
3 necessarily holds, given that x € {A, i?}, y € {A,i?} and x 96 y. In this Case the 
algorithm will only have to. check two specializations of the plan, namely the ones 
where y 96 A and x 96 i?,_which are added when we guarantee that action 2 not 
assert P(A,B). The reason we da not have to check more specializations is that we 
cannot- generate any specializations such-that action 1 does not assert P(A,B), given 
that action 2 cannot assert P(A,B) either. This is much more efficient than having 
to check every possible ground linear completion of this plan. 

However, We are still left with the problems of the efficiency of constraint propa- 
gation. We might ask how planners with extended representational -capabilities deal 
with these problems. SIPE is the best example of a planner with powerful represen- 
tational capabilities.. Furthermore, SIPE is the most efficient planner to date. 

In SIPE, the combinatorial nature of constraint propagation is handled by keeping 
many Of the constraint propagations local, i.e. not performing a global constraint 
cheek every time a constraint is posted. Furthermore, constraint computations are 
not performed every time a constraint is added, .but .rather at-regular intervals. This 
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Figure 9.3: A plan with restricted ranges on variables 


seems to .be an adequate compromise, as the constraint Computations have seldom 
led to a problem [Wilkins, 1988]. 

State independent axioms are handled by computing their derived effects only 
when a new action is inserted into the plan. - The propositions .that are derived in 
this manner are inserted in the add list of . the action that is being inserted. By using 
this method, checking whether an action asserts a proposition is done trivially by 
checking if it codesignates with a proposition in the add list. Of course this can lead 
to. inconsistencies later in planning, but this has not proven to be a serious problem 
With SIPE. 

Relating this method to our truth criterion we can see that it would greatly speed 
up the computation everywhere we need to check if a particular situation, asserts a 
proposition. Although it requires the addition of unsound methods, experience seems 
to bear out that a richer representation makes up for the potential drawbacks. 
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9.7 Summary 

In this chapter we presented a new truth criterion for a powerful plan formalism which 
subsumes most planners proposed to date. In fact, the Only axiom in Our formalism is 
a restatement of the STRIPS assumption. We proved it is sound and complete with 
respect to this representation. We then showed how it gives rise to an algorithm that 
is. more efficient than simply checking every possible completion of a plan. 



Chapter 10 
Further Work 


In this chapter we point out some questions raised by this thesis and propose further 
work that might help resolve these. 


10.1 Real World Applications 

The most important question that needs to be answered is whether predicate relax- 
ation can scale up to real world applications. Since the work presented in this thesis 
was based on a complete planner, real world applications were not within its scope. . 

One way to answer this is to apply predicate-relaxation do an efficient planner. 
SIPE [Wilkins, 1984] is an obvious candidate. In the early stages of this research SIPE 
was used for. some experiments with good results. We hope to some day attempt to 
integrate predicate relaxation into SIPE. 

10.2 Extensions to Predicate Relaxation 

Another interesting avenue to pursue is extending predicate relaxation. This might 
involve trading off correctness for simplicity in generating the relaxed predicates. As 
the efficiency of the planning process is . improved it -is likely that the complexity of 
the relaxed predicates becomes the bottleneck. This then-leads us to new Ways of 
simplifying relaxed predicates, so that they can be evaluated more quickly. 
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Another extension would be to define a new form ef predicate relaxation which can 
take into account the more complex operators available in state of the art planners. 
In this thesis we have assumed a planner which is based on STRIPS-style operators. 
It would-be interesting to come up with a definition which can handle conditional 
operators, take into account resources, etc. 

There is also the possibility of definining /ormu/a relaxation , namely, the relaxation, 
of commonly occuring sub-formulas. This idea has been proposed by Nilsson and 
might result in definitions that are similar to tree plans [Nilsson, 1989]. 


10.3 Implementation of the Classical Truth Cri- 
terion 

Another interesting project might be to build a planner based on the Classical Truth 
Criterion. This planner would be able to support an extended language for repre- 
senting operators, including conditional operators, as well as restricted domains for 
variables. 

It would be interesting to experiment with different ways of trading off complete* 
ness and correctness for efficiency in the truth criterion. The new truth criterion 
would provide a good basis for performing such experiments. 


10.4 Real-time Extensions 

Another area that should be examined is that of improving real-time performance. 
The current extension to predicate relaxation allows a limited form of reactivity, since 
the planner is able tc propose a plausible, action in case it is interrupted. One goal 
of planning research should be to imbue planners with the capability to decide when 
acting is indeed necessary, rather than having to rely on an outside agent to make 
that decision. This is also closely tied to the problem of determining the quality of 
the currently chosen action, since the tradeoff between the improvement of actions 
resulting from future planning and the possible gains of acting immediately is one the 
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planner should be aware of. 

10.5 Operator Abstraction 

More work needs to be done in the held of operator abstraction. This might entail 
automating the process of constructing abstract operators a la Nonlin and Sipe, but 
might also involve designing new forms . of operator abstraction, utilizing approxima- 
tions of operators, and automatically abstracting preconditions and effects of oper- 
ators. Operator, abstraction has been the prevalent form of abstraction in planning 
and automating the process would be a significant advance^. 

10.6 Concluding B,emarks 

This thesis has explored new methods of performing abstraction in planning. We 
hope that the usefulness of abstraction has been clarified, and that the methods, 
primarily predicate relaxation, provide a basis for future research in this area. State 
abstraction has been somewhat overlooked in the planning literature, but is beginning 
to see some resurgence. Furthermore, we stress the importance of exploring ways in 
which to improve the problem solving capabilities. of planners as opposed to their 
representational prowess, an area that has already been much explored. Abstraction 
and planning remain fascinating areas of research that need to be further investigated. 
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